Re: Massive change in Public Cert behaviour coming soon

[brent saner via NANOG <nanog () lists nanog org>]

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.
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/W2UU4EXM5F3APSWC4TRRDFP26KPD4PB2/