On Sat, May 17, 2025, 23:24 Grant Taylor via NANOG <nanog@lists.nanog.org> wrote:
On 5/17/25 7:56 PM, brent saner via NANOG wrote:
SMTPS/SMTP + STARTTLS for MTA MTA does not use id-kp-clientAuth EKU, which is what they're deprecating/removing.
I hope that's the case. But I have questions. Do MTAs actually check the presence of the id-kp-serverAuth and / or id-kp-clientAuth Extended Key Usage value? I don't know. If they do, will they continue to do so in the future? Or will the have a new option to treat id-kp-serverAuth akin to id-kp-clientAuth? I don't know. Time will tell.
Depends on the software/implementation, but if MTAs check EKU policy *at all*, they check it for id-kp-serverAuth, not id-kp-clientAuth. From recollection, I believe most don't as it's strictly defined for web authentication (https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.1.12 ).
Certs are used on MTAs for *identity verification of the server* and *integrity validation/encryption*, not authentication.
I question the veracity of that.
What is the difference between "identity verification of the server" and "authentication (of the server's identity)"? -- I wonder if you were going for "authorization", not "authentication".
I was not. MTAs do not do AAA with each other at all, they're transports. Why would foreign org A be authing with self domain B or vice versa? Identity verification in SMTP boils down to "the EHLO/HELO matches the CN/SAN; an authority I trust has recognized this server is what it says it is". If you show me your driver's license to confirm you are who you say you are, that is quite different than giving me your member number and password of an exclusive club. That club, instead of having member numbers and passwords, could base membership based on real names or driver license numbers- in which case they WOULD use your driver's license for authentication. That is exactly what mTLS auth is. Which MTAs *do not do* with each other.
N.B. the Extended Key Usage values "id-kp-serverAuth" and "id-kp-clientAuth" only differ in that one is "server" and the other is "client". So it really seems like it's the same process, just done to two different entities; "server" vs "client". Per the OID Repository, the "auth" is "authentication", not authorization.
See above. Transports in SMTP do not authenticate, they identify (if at all). The receiving MTA has no contextual object for the sender MTA, there is no account associated with it. Would you say an HTTPS cert "authenticates" a webserver to a client? No, don't be daft. It identifies it.
I have, and know multiple other people that also have, servers authenticate to other servers using the local server's Let's Encrypt certificate. This is particularly nice for servers at client offices that are on dynamic IPs.
Yes, mTLS auth is a thing. MTAs don't do it with each other, though. (Unless, of course, you've got a series of MTAs internally used only. I guess they *could* do auth with each other, but when you send mail to an external org, that's not authenticated.)
The server already has a local Let's Encrypt certificate for various web related things. So why not re-use that certificate for other things like authenticating to the corporate SMTP server and / or the corporate VPN server.
Because any Tom, Dick, and Jane can get an LE cert. X.509 *authentication* operates on the assumption that an issuer only signs certificates for resources valid for the context. But SMTP server at org A does not authenticate to SMTP server at org B. It identifies. Last time I checked, certificate based authentication was considerably
stronger than username and password based authentication.
It is indeed, yes. That's mTLS auth. Which, again, MTAs on the internet do not so, because they're transports- not endpoints.
What's more is that with certificates, each server only needs to keep it's own certificate private key safe. Other servers don't have to keep anything safe on it's behalf. The same can't be said for passwords.
See above. Once you have verified / authenticated identity, then you can start
doing interesting things with authorization. -- After all, that's what's often done with the weaker username & password based authentication.
MTAs verify other MTAs, not authenticate. If they do any authentication at all, it's for the MUA.
It is strictly only used for *authenticating clients*, hence the name, in mTLS (or *client*-driven one-way TLS, which I don't think I've ever actually seen in the wild to my knowledge).
I think what is a client vs server may be a bit surprising. The role of "server" and "client" can, and does, changes depending on who's initiating the connection.
SMTP has no surprises. Note when I say MTA vs. MUA.
A system that was the server receiving an email becomes the client when sending it onward seconds later. It's the same system and has the same certificate to authenticate itself.
Not in SMTP. It's explicitly a transport when delivering mail to another mail server. Hence, MUA.
Which end of the site-to-site VPN tunnel is the server and the client? Does your answer change if one end reboots? What about the other end? Darn cleaning crew and their evil vacuums.
SMTP is not a tunnel. It does not peer.
- local office SMTP relay is a client to the corporate SMTP relay
- site-to-site VPN has both a server (responder) and a client (initiator) - sometimes the difference is which one rebooted / tried to initiate the connection most recently.
I see TLS certificates from Let's Encrypt, et al., used for both of these roles.
This is wholly irrelevant to SMTP wrt X.509. But at that note, it should be an internal CA. It's a lot easier when you only need to trust an issuer instead of trusting an issuer AND then ACL based on Subj. Unless you don't ACL on Subj. See above re: every Tom, Dick, Jane.
The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate.
I see that exact thing happening.
Your users have LE certs? Funny, I wasn't aware LE was issuing certs for username CNs. (They don't.) Unless you mean server machines as MUAs. If so, see above re: Toms, Dicks, Janes.
I see very similar things happening with VPNs.
A quick search makes me think that VoIP a la. SIP-TLS / SRTP will also make use of TLS. It didn't take long at all to find the following phrase in a Cisco document "Support introduced for CN-SAN validation of client certificate." That sure sounds like it's in the mTLS ballpark to me.
That is mTLS, yes. But id-kp-clientAuth is used for X.509 *authentication*, NOT validation (and if we're being RFC-strict, *only* WWW authentication). They're different things in TLS/x.509.
99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
99.999% of 375 billion emails per day (found from a quick search) still leaves several million messages per day that use mutual TLS.
99.999% use mTLS *encryption*. mTLS *auth*. Transports.
I'm one of many on mailop mailing list having a lively discussion about this.
I recommend you join some x.509 or cryptography ones.
I suspect that Google's actions and Let's Encrypt's et al. re-actions will either have zero impact because software won't care about / check the id-kp-serverAuth and / or id-kp-clientAuth -or- it will have a much larger impact than people realize.
It's the former.