Massive change in Public Cert behaviour coming soon
Is anyone elae worried about this? We use public certs for client auth in a number of cases. https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ And here's the Chrome policy document that's forcing the change https://googlechrome.github.io/chromerootprogram/#321-applicant-pki-hierarch... The TLS world is not just Web Browsers, so let me know if this effects you too. Colin Constable
On Sat, May 17, 2025, 18:23 Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone elae worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/VRKIO6IUCJRLENL7FOHWWQV6UXAS3XGK/> We just maintain our own internal PKI/trust anchor at $org for mTLS. There's numerous solutions[0] that have evolved that are a fair bit more robust than `openssl(1)` glued together with bash scripts these days. Running your own PKI with a (or multiple) org-internal CA(s) not only lets you control the KU/EKU etc. of the certs themselves but lets you scope access to anything signed by a given issuer- no futzing with static CN/Subj lists or pattern matching, IP SANs totally fine, not subject to externally-influenced poli(cy|tics), etc. For public-facing it's of course a little higher barrier of entry, but for intra/infra/internal? Cannot be beat, highly recommend. [0] Personal recommendation, https://developer.hashicorp.com/vault/docs/secrets/pki or https://openbao.org/docs/secrets/pki/
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP... -- William Herrin bill@herrin.us https://bill.herrin.us/
Once upon a time, William Herrin <bill@herrin.us> said:
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP...
Who is using Let's Encrypt web server certs for SMTP client authentication? -- Chris Adams <cma@cmadams.net>
nanog@lists.nanog.org (Chris Adams via NANOG) wrote:
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ Does seem like it might have an impact on SMTP...
Who is using Let's Encrypt web server certs for SMTP client authentication?
More people than you expect, I suppose. Might as well raise my own hand - I myself could easily do with self-signed, but there are more users that use trashy A**le tools that won't really budge if you're a non-technical person. Anyway, this change is not impacting server auth, only client auth, which not many people outside of larger companies will be using. El el
Chris Adams via NANOG <nanog@lists.nanog.org> writes:
Once upon a time, William Herrin <bill@herrin.us> said:
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP...
Who is using Let's Encrypt web server certs for SMTP client authentication?
I am quite extensively - I should note that several hosting scripts that deploy web/email/mysql etc services LAMP stacks etc use the tls cert provided to the domain hosted on a "server" also for smtp servers with a dotted line to mailman where that is also installed. Those certs aren these days almost always going to be Lets Encrypt DKIM, SPF, DMARC are already very fussy and can be fiddly as it is. I don't see the benefit in having separate certs for each application on a domain/zone beyond having yet another "vital" thing to be broken and so having to keep an eye on with all the hassle and cost that can imply. Also I am not entirely clear what the implications of this change means as it is not spelt out. Will we have to setup a private PKI for each smtp / domain instance once LE bows to the will of the great google thought policeman in its cloud? If so are there any tooling / scripts / I can add to keep continuity? e.g., acme equivalent to self generate a cert and will this be recognised as a valid cert rather than fall into the self signed ghetto that the web browser CA lists like to shove the rest of us into? It also begs a question. If running one's own certs authority pki for email, apps, messaging, tunnels and so on are so great why not great for my websites and web apps as well? -- Christian de Larrinaga
On Mon, May 19, 2025, 05:44 Christian de Larrinaga via NANOG < nanog@lists.nanog.org> wrote:
Chris Adams via NANOG <nanog@lists.nanog.org> writes:
Once upon a time, William Herrin <bill@herrin.us> said:
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP...
Who is using Let's Encrypt web server certs for SMTP client authentication?
I am quite extensively - I should note that several hosting scripts that deploy web/email/mysql etc services LAMP stacks etc use the tls cert provided to the domain hosted on a "server" also for smtp servers with a dotted line to mailman where that is also installed. Those certs aren these days almost always going to be Lets Encrypt
Your users send mail with a Let's Encrypt *client certificate*? Meaning they log into the SMTP server to gain the ability to send *originating mail* with an LE cert? (MUA -> MTA) I'd recommend they not do that. Use a private CA for clients if you're doing mTLS auth. If they are simply using TLS to connect to the mail server and logging in with a username/password instead of/and don't need a *client certificate*, they *aren't* using LE certs for authentication and are wholly unaffected by this change. This is wholly different from delivering mail to other domains (MTA -> MTA). That doesn't use id-kp-clientAuth at all whatsoever either, and has been pointed out, most CAs never even issued certs with it set. You'll be fine.
DKIM, SPF, DMARC are already very fussy and can be fiddly as it is.
True, but a welcome change IMHO. They really do cut down on spam and rogue SMTP.
I don't see the benefit in having separate certs for each application on a domain/zone beyond having yet another "vital" thing to be broken and so having to keep an eye on with all the hassle and cost that can imply.
You don't need to, you can reuse certs for multiple services if you have multiple running within the same identity (typically FQDN). This change literally only affects *mTLS*, which very few implementations use. If you were using it, you'd know you were using it.
Also I am not entirely clear what the implications of this change means as it is not spelt out. Will we have to setup a private PKI for each smtp / domain instance once LE bows to the will of the great google thought policeman in its cloud?
Nope. You'll be fine using LE certs for SMTP. You're only affected if doing mTLS for SMTP, and if you are you'd know you are. If so are there any tooling / scripts / I can add to keep continuity?
e.g., acme equivalent to self generate a cert and will this be recognised as a valid cert rather than fall into the self signed ghetto that the web browser CA lists like to shove the rest of us into?
"Valid" and "verified" are kind of tricky in TLS/X.509. The reason LE certs are valid in browsers, mail client software, etc. is because their intermediate is signed as an issuer by the ISRG root. The ISRG root is recognized as a trusted authority by most/all devices' trust stores. (This is why you need to include the intermediate cert AND the leaf or "server" certificate -- so the remote end has a complete "chain" to verify.) In other words, device A has ISRG root certificate installed and trusted. ISRG signs LE's certificate and grants it issuer. LE's certificate then sign your server's certificate (the leaf). For a private CA to be trusted, you'd need to petition each and every trust store distributor to include your root as something called a trust anchor. Mozilla, Google, Apple, and Microsoft are generally the ones that'd get you the most coverage (Linux distros usually use Mozilla's, etc. for their system trust store). This is...a process. A long, arduous process and each trust store distributor has their own rigorous set of rules (like Google now requiring that issued leaf certs not have id-kp-clientAuth set). The alternative is to explicitly add your root as a trusted anchor to *each device*. This is easy in a corporate environment through config management, GPOs, etc. but good luck with the public at-large. (Sidenote, you should only install and trust roots you are confident are safe. Private CAs are what make transparent proxies able to decrypt HTTPS traffic to domains the org does not own, for instance.) So TL;DR: no. There's not just some script or tool you can run to get your private CA added as a "wide-trust"/"widely-trusted" anchor.
It also begs a question. If running one's own certs authority pki for email, apps, messaging, tunnels and so on are so great why not great for my websites and web apps as well?
It's great for *intranet*, which is where you'd typically find mTLS/mTLS auth. For public-facing, you want a cert from a wide-trust (or one of its intermediates- like Let's Encrypt) because you do not have the ability to install an anchor on foreign/general public devices. (For good reason.)
On Sat, May 17, 2025, 19:34 William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Sat, May 17, 2025 at 4:23 PM Colin Constable via NANOG <nanog@lists.nanog.org> wrote:
Is anyone else worried about this? We use public certs for client auth in a number of cases.
https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/
Does seem like it might have an impact on SMTP...
SMTPS/SMTP + STARTTLS for MTA <-> MTA does not use id-kp-clientAuth EKU, which is what they're deprecating/removing. Certs are used on MTAs for *identity verification of the server* and *integrity validation/encryption*, not authentication. 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). The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate. 99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
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.
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". 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. 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. 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. Last time I checked, certificate based authentication was considerably stronger than username and password based authentication. 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. 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.
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. 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. 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. - 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.
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. 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.
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. I'm one of many on mailop mailing list having a lively discussion about this. 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. -- Grant. . . .
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.
On Sun, May 18, 2025 at 8:02 AM brent saner via NANOG <nanog@lists.nanog.org> wrote:
Transports in SMTP do not authenticate, they identify (if at all).
Hi Brent, I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization. Which now that I think about it sounds a lot like there's a layer violation in giving TLS certificates a "for this purpose" tag at all. I knew there was a reason I didn't like it but I was having trouble putting my finger on it. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 5/18/25 10:26 AM, William Herrin via NANOG wrote:
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
+1
Which now that I think about it sounds a lot like there's a layer violation in giving TLS certificates a "for this purpose" tag at all. I knew there was a reason I didn't like it but I was having trouble putting my finger on it.
I don't think it's a layering violation. Mutual TLS authenticates each party to the other. Then each party is free to do whatever they want with that authenticated identity. The TLS itself has nothing to do with what what is done with the authenticated identity information. -- Grant. . . .
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
"I am FOO." = Identification "This is proof I am FOO" = Authentication On Sun, May 18, 2025 at 11:28 AM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025 at 8:02 AM brent saner via NANOG <nanog@lists.nanog.org> wrote:
Transports in SMTP do not authenticate, they identify (if at all).
Hi Brent,
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
Which now that I think about it sounds a lot like there's a layer violation in giving TLS certificates a "for this purpose" tag at all. I knew there was a reason I didn't like it but I was having trouble putting my finger on it.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/JSL25WHJ...
On 5/18/25 12:14 PM, Tom Beecher via NANOG wrote:
"I am FOO." = Identification
"This is proof I am FOO" = Authentication
Okay. I think that's a fair distinction. Based on these meanings, I think that most contemporary MTAs use some form of (weak) authenticated identity. The most common that I see is reverse DNS with forward DNS confirmation. A less common form of (client) authentication is username & password. N.B. Only less common in that there are more MTA-to-MTA connections than there are MUA-to-MTA connections. -- I'm eliding illegitimate connections like credential stuffing attacks. I haven't seen a properly configured Internet accessible MTA not do any form of authentication in many years. More like multiple decades at this point. So I posit that Brent's "SMTP do not authenticate" statement is outdated at best. What is done with that authenticated identity is a down-stream and independent of the authentication process itself. - Maybe it's not used. - Maybe it's only used for logging (Received: header and / or SYSLOG). - Maybe it's used to alter the what the client is allowed to do. -- Grant. . . .
On Sun, May 18, 2025, 13:30 Grant Taylor via NANOG <nanog@lists.nanog.org> wrote:
On 5/18/25 12:14 PM, Tom Beecher via NANOG wrote:
"I am FOO." = Identification
"This is proof I am FOO" = Authentication
Okay. I think that's a fair distinction.
Based on these meanings, I think that most contemporary MTAs use some form of (weak) authenticated identity. The most common that I see is reverse DNS with forward DNS confirmation. A less common form of (client) authentication is username & password.
N.B. Only less common in that there are more MTA-to-MTA connections than there are MUA-to-MTA connections. -- I'm eliding illegitimate connections like credential stuffing attacks.
I haven't seen a properly configured Internet accessible MTA not do any form of authentication in many years. More like multiple decades at this point.
So I posit that Brent's "SMTP do not authenticate" statement is outdated at best.
MTAs don't authenticate to each other. They *usually* verify the certm but this *is not* authentication- there is no context given to the idemtity, merely that the public key is trusted.
What is done with that authenticated identity is a down-stream and independent of the authentication process itself.
If authentication is done on an identity provided, *that is downstream*. TLS, by itself, is not authentication. Encryption and the trust/validity/verification if it is *not* authentication. (Internet-facing) MTAs do *not* allow/disallow entry of the service based on the identity itself.
On 5/18/25 4:09 PM, Randy Bush via NANOG wrote:
I think that most contemporary MTAs use some form of (weak) authenticated identity. The most common that I see is reverse DNS with forward DNS confirmation. A less common form of (client) authentication is username & password. DANE
DKIM, actually. And it's not weak, modulo use of DNS with its dodgy DNSSec deployment. Mike
It appears that Michael Thomas via NANOG <nanog@lists.nanog.org> said:
On 5/18/25 4:09 PM, Randy Bush via NANOG wrote:
I think that most contemporary MTAs use some form of (weak) authenticated identity. The most common that I see is reverse DNS with forward DNS confirmation. A less common form of (client) authentication is username & password. DANE
DKIM, actually.
No, really DANE. If you publish TLSA records for your mail server's certs, and you screw up and the TLSA doesn't match the cert, mail clients that do DANE, such as Comcast's, won't send you mail. That's pretty strong. MTA-STS does the same thing more kludgily for people who don't like DNSSEC. R's, John PS: You can guess how I learned about that.
John Levine via NANOG <nanog@lists.nanog.org> writes:
MTA-STS does the same thing more kludgily for people who don't like DNSSEC.
What if I don't like public CA certificates for email servers? Will MTA-STS stay optional, or will it be "optional" like DKIM and SPF? AFAICS, we did not need MTA-STS. It is an attempt to solve the same problem DANE solved a long time ago, but adding several new problems: - server and client must agree on trusted CAs, but the list is unspecified - the spec mandates not only a special purpose DNS policy label ("_mta-sts"), but also special purpose host name ("mta-sts") - the latter name must also have a certificate - configuration and operation is way more complicated than DANE, requiring a web server in addition to DNS configuration - the web server is a single point of failure in the design, and must be duplicated in different ASes if you want anything resembling DANE robustness - the web server is just smoke and mirrors, adding nothing to the provided trust. MTA-STS is only as trustworthy as the _mta-sts and mta.sts DNS records. DNSSEC is required in practice if you are going to trust them. But why do you need MTA-STS if you can do DANE? These problems are worse for small sites than for the dominant players. Just like DMARC/SPF/DKIM policies, small sites are mistrusted unless they implement *all* available protection mechanisms. So they can't choose between DANE and MTA-STS. They have to do both. And where the dominant players run their own CA which they force others to trust, the small site has to carefully select some CA which is trusted by every MTA-STS service out there. The operational cost of a redundant web service is pretty much independent of email volume. It will be significant if you run a low volume email server. I guess it is possible that this is just an accident. Hanlon's razor etc. But traditional Internet email handled by small single domain servers has been under attack for a long time. The effect of MTA-STS is yet another hard blow. And given DANE, this is the *only* effect. Why don't we just deprecate MTA-STS and make DANE mandatory, while it is still possible? Bjørn
Bjørn Mork via NANOG <nanog@lists.nanog.org> writes:
John Levine via NANOG <nanog@lists.nanog.org> writes:
MTA-STS does the same thing more kludgily for people who don't like DNSSEC.
More kludgily and less secure. It even says so, right in the RFC.
AFAICS, we did not need MTA-STS. It is an attempt to solve the same problem DANE solved a long time ago, but adding several new problems:
Yup. It's Google and Microsoft creating a kludge to avoid DNSSEC -- and Microsoft has since given in, and implemented DANE and DNSSEC for their mail systems, so these days it's just a Google thing.
Why don't we just deprecate MTA-STS and make DANE mandatory, while it is still possible?
That would be nice. Also, I want a pony. :) -tih -- The creation of the state of Israel was a regrettable mistake. It is time to undo this mistake, and finally re-establish a free Palestine.
On Mon, 19 May 2025, Bjørn Mork wrote:
MTA-STS does the same thing more kludgily for people who don't like DNSSEC. What if I don't like public CA certificates for email servers?
If you don't like it, don't use it. The IETF isn't the Network Police.
Will MTA-STS stay optional, or will it be "optional" like DKIM and SPF?
Given that it does something completely different and is intnded to protect mail you receive rather than mail you send, no.
Why don't we just deprecate MTA-STS and make DANE mandatory, while it is still possible?
It's an open secret that MTA-STS exists because one of the large mail providers doesn't want to use DNSSEC. The IETF is still not the Network Police so there's nothing we can do about it. R's, John
On 5/19/25 9:38 AM, John R. Levine via NANOG wrote:
On Mon, 19 May 2025, Bjørn Mork wrote:
Why don't we just deprecate MTA-STS and make DANE mandatory, while it is still possible?
It's an open secret that MTA-STS exists because one of the large mail providers doesn't want to use DNSSEC. The IETF is still not the Network Police so there's nothing we can do about it.
As it turns out DKIM's use of DNS to fetch public keys was mistake, which IIM (the IM part of DKIM) got right, and would have made the underlying protocol more reusable for other applications. Water under the bridge, but if anybody is implementing this, it's just more proof that the complaints back then about performance aged like milk. Mike
Bjørn Mork sayeth:
Why don't we just deprecate MTA-STS and make DANE mandatory, while it is still possible?
IPV6 and RPKI called. They said they were here first and are still waiting to be fully implemented. They said feel free to take a number and hang out for another 10-20 years or so as there are ~reasons~ to not implement things. XD Regards, Michael
On Sun, May 18, 2025, 10:27 William Herrin <bill@herrin.us> wrote:
On Sun, May 18, 2025 at 8:02 AM brent saner via NANOG <nanog@lists.nanog.org> wrote:
Transports in SMTP do not authenticate, they identify (if at all).
Hi Brent,
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
I'd argue against that. "You *know me* as FOO and here is proof" is authentication. Identity verification is only half of authentication ("here is proof"), the other half is a mapping of entity/identity from that ("you *know me* as"). (And then *what that entity* has access to (and how, etc.) is authorization. I think we can all agree on that.) I can use the same username, DN, whatever across multiple services but unless that service has knowledge of that identity, I'm not going far. This is why all EAP-TLS is TLS but not all TLS is EAP-TLS. Take a stab at what the "A" in "EAP" is (RFC 3748). Or why TLS-PSK is a thing (RFC 4279). There's not even a cert involved in that- not even a public key since it's symmetric. This is because the purpose of *TLS*, specifically, is encryption. Its purpose is to protect data, not authenticate to a service. mTLS is closer to an extension of TLS handshaking; it's just an additional verification that the other end's *encryption context* is verified (signed by a trusted source) and *valid* (not in expiry/is after allowed usage date/time, etc.) Which is why it's "*mutual* TLS" and not EAP. All mTLS auth is mTLS. Not all mTLS is mTLS auth. The verified identity may then be FURTHER used for mapping to an internal context. It is at *this point*, which MTAs do not do, that it becomes authentication ("it identifies as being in this/these OUs/groups", "it belongs to this ORG", etc.). The validity *establishes* the trust that "yep, I saw these claims at the time of creation." The issuer provides no verification *of those claims*, just that they were *made*. This is *also* why id-kp-(server|client)Auth EKUs exist in the first place. Per 4.2.1.12 of RFC 5280, these *specifically* are bits that are *only* and *optionally* valid for *service-defined behavior*, and not tied to the actual verification of the issuance nor the issuance itself. Trust is not the entirety of authentication. It is erroneous to understand it as such.
Which now that I think about it sounds a lot like there's a layer violation in giving TLS certificates a "for this purpose" tag at all. I knew there was a reason I didn't like it but I was having trouble putting my finger on it.
They were established for cryptographic contexts in which there is a clear service (web, specifically) with a defined provider and consumer (or "server" and "client").
On Sun, May 18, 2025 at 12:04 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025, 10:27 William Herrin <bill@herrin.us> wrote:
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
I'd argue against that. "You *know me* as FOO and here is proof" is authentication. Identity verification is only half of authentication ("here is proof"), the other half is a mapping of entity/identity from that ("you *know me* as").
Hi Brent, This isn't parsing for me. You're mapping what to what?
(And then *what that entity* has access to (and how, etc.) is authorization. I think we can all agree on that.)
"This identity may only be used for clients verifying servers," smells like authorization to me. The purpose of signing an encryption key (the thing letencrypt does) is to authenticate that the presented encryption key belongs to the claimed identity, in this case a DNS domain name. Not authorize it for a particular use. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
"This identity may only be used for clients verifying servers," smells like authorization to me.
It's not. It's "This certificate can only be used to authenticate me if it is being used in the manner with which I specify." Ex 1 : 1. Alice creates certificate A, with the EKU set to Server Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, but since it is only allowed to be used as Server Auth, not Client Auth, then *authentication* fails. No authorization of anything ever occurs here, because authentication has failed. Ex 2 : 1. Alice creates certificate A, with the EKU set to Client Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, and it is allowed to be used for Client Auth. *Authentication* succeeds. Now that Alice has been authenticated, Bob can determine if she is *authorized* to do the thing she is trying to do. On Sun, May 18, 2025 at 8:11 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025 at 12:04 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025, 10:27 William Herrin <bill@herrin.us> wrote:
I'm unclear what distinction you're drawing between "identify" and "authenticate." "I am who I say I am," is the sum total of authentication. Everything beyond that gets into authorization.
I'd argue against that. "You *know me* as FOO and here is proof" is authentication. Identity verification is only half of authentication ("here is proof"), the other half is a mapping of entity/identity from that ("you *know me* as").
Hi Brent,
This isn't parsing for me. You're mapping what to what?
(And then *what that entity* has access to (and how, etc.) is authorization. I think we can all agree on that.)
"This identity may only be used for clients verifying servers," smells like authorization to me. The purpose of signing an encryption key (the thing letencrypt does) is to authenticate that the presented encryption key belongs to the claimed identity, in this case a DNS domain name. Not authorize it for a particular use.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5Y4OLU5B...
On Sun, May 18, 2025, 20:28 Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
"This identity may only be used for clients verifying servers," smells like authorization to me.
It's not. It's "This certificate can only be used to authenticate me if it is being used in the manner with which I specify."
Ex 1 :
1. Alice creates certificate A, with the EKU set to Server Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, but since it is only allowed to be used as Server Auth, not Client Auth, then *authentication* fails.
No authorization of anything ever occurs here, because authentication has failed.
Ex 2 : 1. Alice creates certificate A, with the EKU set to Client Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, and it is allowed to be used for Client Auth. *Authentication* succeeds.
Now that Alice has been authenticated, Bob can determine if she is *authorized* to do the thing she is trying to do.
Generally yes, precisely this, but what I think many are missing is TLS verification itself is still not even authentication unless actual identification context is associated (e.g. a certificate attribute is given meaning). See RFC 4949, "authenticate" definition, second and third deprecations. #5 in both the above examples is *service*-specific, and should probably be split into: == 5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication. == Internet-facing MTAs do not do 5.b. when communicating with other MTAs (and typically don't even do it for clients, opting instead for doing encryption via TLS and authentication via SASL). Most wide-trust CAs don't even issue certs with id-kp-clientAuth set, I wasn't aware LE was even doing so until I found out about them removing it- because it's generally not useful for internet-facing resources unless you control the authority.
Yes, absolutely correct. I was just generalizing the example, perhaps unclearly. On Sun, May 18, 2025 at 10:04 PM brent saner via NANOG < nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025, 20:28 Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
"This identity may only be used for clients verifying servers," smells like authorization to me.
It's not. It's "This certificate can only be used to authenticate me if it is being used in the manner with which I specify."
Ex 1 :
1. Alice creates certificate A, with the EKU set to Server Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, but since it is only allowed to be used as Server Auth, not Client Auth, then *authentication* fails.
No authorization of anything ever occurs here, because authentication has failed.
Ex 2 : 1. Alice creates certificate A, with the EKU set to Client Auth Only. 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* herself. 3. Bob says "Hello, prove you are Alice." 4. Alice sends certificate A. 5. Bob verifies certificate A cryptographically, and it is allowed to be used for Client Auth. *Authentication* succeeds.
Now that Alice has been authenticated, Bob can determine if she is *authorized* to do the thing she is trying to do.
Generally yes, precisely this, but what I think many are missing is TLS verification itself is still not even authentication unless actual identification context is associated (e.g. a certificate attribute is given meaning). See RFC 4949, "authenticate" definition, second and third deprecations.
#5 in both the above examples is *service*-specific, and should probably be split into:
==
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
==
Internet-facing MTAs do not do 5.b. when communicating with other MTAs (and typically don't even do it for clients, opting instead for doing encryption via TLS and authentication via SASL).
Most wide-trust CAs don't even issue certs with id-kp-clientAuth set, I wasn't aware LE was even doing so until I found out about them removing it- because it's generally not useful for internet-facing resources unless you control the authority. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TFGSQP42...
On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
See RFC 4949, "authenticate" definition
Hi Brent, From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource." In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization.
second and third deprecations.
Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate."
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified. I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, May 18, 2025, 22:32 William Herrin <bill@herrin.us> wrote:
On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
See RFC 4949, "authenticate" definition
Hi Brent,
From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource."
In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization.
Where, precisely, is this public key associated with FQDNs in SMTP? What are you verifying the CN/SANs against?
second and third deprecations.
Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate."
How about the next entry, "authentication": "(I) The process of verifying a claim that a system entity or system resource has a certain attribute value." What "system entity" or "system resource" are you authenticating against in pure, straightforward TLS? CAs only provide trust and integrity of presented identity attributea, they don't store, manage, or otherwise control that identity. The Thawte intermediate keypairs have no clue what an "example.com" is, they just can provide evidence that was part of data that they signed. This is why "verification/validation" is preferred over "authentication" when *just* TLS is concerned - because "authentication" does not fit.
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified.
I'll side with IETF on this, thanks.
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
Cryptographic exchange is not AAA. It can be used WITH AAA by *reusing the TLS identity within the service*, but it's not AAA - TLS is not a service itself, just as e.g. SCTP isn't a service. TLS is a specified transport layer providing encryption with multiple facilities ensuring that *communication* with the remote end can be trusted. Data hasn't even *hit the actual service yet*. All current RFC specifies AAA in conjunction with system resources/system entities, which have their own RFC-defined meanings, if you'd like to go down that route, but there's a reason "authenticate" was deprecated in favor of "verify" when certificates are confirmed against a trust chain.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified.
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
You could state that the certificate says "Here are my identification credentials, but I only authorize you to accept them if they have been presented to you while doing FOO." This is semantically correct , it's just not common verbiage used to describe what is occurring, so insufficient pedantry. "The authentication was complete when the identity was verified" is also verbiage that's clunky, and also not accurate. When PKI is used, authentication only is completed after a certificate is processed and passed as valid. ( RFC5280, Sec 6.1.3 - 6.1.5. ) In the example given, if the cert has a critical EKU of id-kp-serverAuth , and it's presented as clientAuth, the cert processing fails, therefore authentication did not succeed. On Sun, May 18, 2025 at 11:33 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
See RFC 4949, "authenticate" definition
Hi Brent,
From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource."
In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization.
second and third deprecations.
Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate."
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified.
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OZ3BMILS...
On Mon, May 19, 2025 at 5:36 AM Tom Beecher <beecher@beecher.cc> wrote:
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
You could state that the certificate says "Here are my identification credentials, but I only authorize you to accept them if they have been presented to you while doing FOO." This is semantically correct , it's just not common verbiage used to describe what is occurring
Hi Tom, I will buy that and confess to being pedantic about it.
"The authentication was complete when the identity was verified" is also verbiage that's clunky, and also not accurate. When PKI is used, authentication only is completed after a certificate is processed and passed as valid. ( RFC5280, Sec 6.1.3 - 6.1.5. ) In the example given, if the cert has a critical EKU of id-kp-serverAuth , and it's presented as clientAuth, the cert processing fails, therefore authentication did not succeed.
My point, the one where this pedantry started, was that this is yet another example of IETF layer violation: instead of a clean authentication step, they added authorization stuff in there, the "extended key usage" elements. Protocol layer violations usually cause trouble somewhere down the line as this one may be doing now. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
I suspect the idea of key usage was authentication-related. By specifying that a key is only used for server authentication, it prevents a hypothetical class of attacks where, say, you present one server's certificate as a client certificate to another server, pass traffic between the two servers - successfully authenticating as something you aren't, but still being unable to forge messages, but the connection may still have unintended effects (see cross-protocol request forgery). Whether such attacks actually work, I don't know (probably not) - but presumably it felt prudent to the designers to entirely rule out the situation. On 19 May 2025 5:31:45 am GMT+02:00, William Herrin via NANOG <nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
See RFC 4949, "authenticate" definition
Hi Brent,
From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource."
In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization.
second and third deprecations.
Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate."
5.a.) Bob verifies certificate A cryptographically; it's verification (may) determine validity/continuance of TLS communication 5.b.) (Only in certain services) The usage of the certificate is verified in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), which (may) determine continuance of TLS communication.
I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified.
I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OZ3BMILS...
On Thu, May 22, 2025 at 3:18 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
By specifying that a key is only used for server authentication, it prevents a hypothetical class of attacks where, say, you present one server's certificate as a client certificate to another server, pass traffic between the two servers - successfully authenticating as something you aren't, but still being unable to forge messages, but the connection may still have unintended effects (see cross-protocol request forgery).
A certificate authenticates an encryption public key and the identity claimed to be associated with it. A man in the middle can pass that key onward, but he won't be able to encrypt or decrypt anything with the associated private key since he does not possess the associated private key. This works in either direction which is rather the point. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, May 18, 2025 at 7:04 PM brent saner via NANOG <nanog@lists.nanog.org> wrote:
Most wide-trust CAs don't even issue certs with id-kp-clientAuth set, I wasn't aware LE was even doing so until I found out about them removing it- because it's generally not useful for internet-facing resources unless you control the authority.
Yes. This. Most (almost all?) of the standard server certs from other certificate authorities have never included client auth EKU. All of those applications where someone got their certificate from another CA and it just works, will just work with the Let's Encrypt certs after the change. However, a few people have stated they use Let's Encrypt certificates for things that do use client authentication. Let's Encrypt is run by the Internet Security Research Group (ISRG), a non-profit organization. They want to support the community as best they can. If there is a significant community out there using their certificates in this manner, let them know. Bet yet, back it up with offers of sponsorship or direct assistance in providing the service.
On Sun, May 18, 2025 at 6:28 PM Tom Beecher <beecher@beecher.cc> wrote:
"This identity may only be used for clients verifying servers," smells like authorization to me.
It's not. It's "This certificate can only be used to authenticate me if it is being used in the manner with which I specify."
Hi Tom, I'm pretty sure that is exactly wrong. You've mixed the authentication and authorization components. Identity is identity regardless of the use to which it is put. The certificate either authenticates its principal or it does not *before* considering any use to which that identity is put. Considering the use prior to establishing the veracity of the identity would be a pretty clear layer violation. You finish authentication first. *Then* you decide whether it's acceptable for the proposed transaction (authorization). You connect to me with SSH and enter "root" with the right password, you have authenticated yourself as root. I'm not gonna let you in because I've decided that root is not authorized to connect via ssh, but that has nothing to do with the authentication step. If you've figured out the password, you are verified to be root. See how that works? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, May 18, 2025, 22:58 William Herrin via NANOG
(SNIP) You connect to me with SSH and enter "root" with the right password, you have authenticated yourself as root. I'm not gonna let you in because I've decided that root is not authorized to connect via ssh, but that has nothing to do with the authentication step. If you've figured out the password, you are verified to be root. See how that works?
...What version of SSH service are you running? If this is true, it's not OpenSSH. It does username checks/logic before authentication. https://man.openbsd.org/sshd_config#PermitRootLogin https://man.openbsd.org/sshd_config#AuthenticationMethods It has no way of determining what auth challenges to send to/apply to the client if it didn't.
Hi, On 19.05.2025 03:27, Tom Beecher via NANOG wrote:
5. Bob verifies certificate A cryptographically, but since it is only allowed to be used as Server Auth, not Client Auth, then*authentication* fails.
Authentication: are you are who you say you are? Authorization: Are you allowed to do something, or you're prohibited from doing something. The only reason anyone can claim this is authentication is because the first question is answered not simply by the cryptographic validation but the attestation of the signer, and the signer refuses to attest if a key is used for purposes other than those the signer permits. In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using the certificate for certain purposes. There are $REASONs for this, but I'd really like to hear them. Eliot
On 5/19/25 11:54 PM, Eliot Lear via NANOG wrote:
Hi,
On 19.05.2025 03:27, Tom Beecher via NANOG wrote:
5. Bob verifies certificate A cryptographically, but since it is only allowed to be used as Server Auth, not Client Auth, then*authentication* fails.
Authentication: are you are who you say you are?
Authorization: Are you allowed to do something, or you're prohibited from doing something.
The only reason anyone can claim this is authentication is because the first question is answered not simply by the cryptographic validation but the attestation of the signer, and the signer refuses to attest if a key is used for purposes other than those the signer permits.
In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using the certificate for certain purposes. There are $REASONs for this, but I'd really like to hear them.
I have always assumed $BUSINESSMODEL. More certs issued: $$. More complicated and the potential for churn due to changing roles, etc? PROFIT! Entangling authz is a great way to achieve that, even though just a simple lookup for permissions, roles, etc, etc in an online database (eg, LDAP, but it can be anything) is so much easier (and natural, imo). It's bad enough we're stuck with the legacy of certificates in a world that largely doesn't need their unique capability (offline verification), but entangling even more stuff with them like authz makes a historical mess even worse. Mike
On Tue, May 20, 2025 at 9:14 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
On 19.05.2025 03:27, Tom Beecher via NANOG wrote: In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using
EKU is also an optional extension. Nothing in the standard says you have to use it. Nothing in the standard suggests that you should or ought to use it. I would strongly suggest that you don't need to set an EKU, and the CAs should not add an EKU unless you the person who are applying for the certificate requested that they do so. The CA could also sign a certificate for you which authorizes you to sign your own certificates for the same subject list, and provide you the capability to compartmentalize your keys however is appropriate for your deployment.
the certificate for certain purposes. There are $REASONs for this, but I'd really like to hear them.
I believe that's because a X.500 directory also has what I would consider to be administrative controls. One of the things the CA might want to do is differentiate certain services. For example: Your identity is proven, but the CA wishes to only authorize you to digitally sign to verify the authorship of a document or email, and not grant the ability to sign a piece of software or code without an extra $1000 fee paid to the CA for "Code signing access". One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. For example: You have a secret key you want to install on a web server, and a secret key your server to sign authentication tickets with. Both certificates are for the same FQDN, but the web server certificate is at higher risk of the secret key being comrpomised in your specific deployment, while your secret key for the Token signing certificate is stored on a #11 smartcard or hardware security device (HSD), Etc. That means it's a security issue if a relying party would accept a token signed by the web server's secret key. In order to take the appropriate responsibility levels for safeguarding your public key per application - You need a mechanism of adding qualifications to the certificates issued to you which will be visible to the relying parties of the certificate and enforce the restrictions the Subject of the certificate has chosen for their secret key management purposes.
Eliot -- -JA
On 5/20/25 8:10 AM, Jay Acuna via NANOG wrote:
On Tue, May 20, 2025 at 9:14 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
On 19.05.2025 03:27, Tom Beecher via NANOG wrote: In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using [clip] I believe that's because a X.500 directory also has what I would consider to be administrative controls.
One of the things the CA might want to do is differentiate certain services. For example: Your identity is proven, but the CA wishes to only authorize you to digitally sign to verify the authorship of a document or email, and not grant the ability to sign a piece of software or code without an extra $1000 fee paid to the CA for "Code signing access".
That begs the question of why a CA should have any role in such administrative work. Why should a CA be involved in authz at all when a simple authz lookup provides the same functionality without all of the issues and potentially $$$ of involving at CA? Doubly true when certificates have expirey considerations (cf: revocation) where changing authz tends to want to be *immediate* (eg, you just got fired and all work related authz must be disabled immediately). Involving revocation servers just clouds the issue even more, and begs the question of why the bearer needs to carry that part of the authz database rather than servers in the net. Why? It has been an unfortunate part of internet security that certificates have muddied the waters about identity. Nobody in their right mind would want a login user to carry around a bundle of bits on their laptop of what they are authorized to do when a simple database lookup suffices along with the myriad of other things that the backend servers need to know about individual users. It is completely sufficient to associate public keys with an identity in the backend to authenticate that identity and not need a binding to a name the user carries around (eg, a cert) which is how the rest of the world is organized. It should be noteworthy that the symmetric key equivalent -- Kerberos -- fell out a favor decades ago. I wrote an essay describing the current mess that certs and cert-think cause here: https://rip-van-webble.blogspot.com/2021/03/certificates-confuse-everything....
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. For example: You have a secret key you want to install on a web server, and a secret key your server to sign authentication tickets with.
Or you just generate different key pairs and associate the keys with different capabilities in the backend. key-gen is cheap, and there is about zero motivation for some heavy CA-like machinery with all of its ops and maintenance considerations to be involved at all. DKIM got that right. DANE seems to have gotten that right. Webauthn seems to gotten that right. Everything that I'm aware of goes off the rails when certs are introduced. Web/TLS is the real exception and mainly because the web grew up with it. Every other use is suspect until proven necessary, IMO. Mike
Nobody in their right mind would want a login user to carry around a bundle of bits on their laptop of what they are authorized to do
EKU is not 'This certificate defines what the user is allowed to do'. It is "This certificate is valid to authenticate ONLY IF it is being presented to you in a specific context." On Tue, May 20, 2025 at 12:56 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
On 5/20/25 8:10 AM, Jay Acuna via NANOG wrote:
On Tue, May 20, 2025 at 9:14 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
On 19.05.2025 03:27, Tom Beecher via NANOG wrote: In other words, EKU is a horrible mishmash of authentication and authorization because the signer is prohibiting the principal from using [clip] I believe that's because a X.500 directory also has what I would consider to be administrative controls.
One of the things the CA might want to do is differentiate certain services. For example: Your identity is proven, but the CA wishes to only authorize you to digitally sign to verify the authorship of a document or email, and not grant the ability to sign a piece of software or code without an extra $1000 fee paid to the CA for "Code signing access".
That begs the question of why a CA should have any role in such administrative work. Why should a CA be involved in authz at all when a simple authz lookup provides the same functionality without all of the issues and potentially $$$ of involving at CA? Doubly true when certificates have expirey considerations (cf: revocation) where changing authz tends to want to be *immediate* (eg, you just got fired and all work related authz must be disabled immediately). Involving revocation servers just clouds the issue even more, and begs the question of why the bearer needs to carry that part of the authz database rather than servers in the net. Why?
It has been an unfortunate part of internet security that certificates have muddied the waters about identity. Nobody in their right mind would want a login user to carry around a bundle of bits on their laptop of what they are authorized to do when a simple database lookup suffices along with the myriad of other things that the backend servers need to know about individual users. It is completely sufficient to associate public keys with an identity in the backend to authenticate that identity and not need a binding to a name the user carries around (eg, a cert) which is how the rest of the world is organized. It should be noteworthy that the symmetric key equivalent -- Kerberos -- fell out a favor decades ago.
I wrote an essay describing the current mess that certs and cert-think cause here:
https://rip-van-webble.blogspot.com/2021/03/certificates-confuse-everything....
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. For example: You have a secret key you want to install on a web server, and a secret key your server to sign authentication tickets with.
Or you just generate different key pairs and associate the keys with different capabilities in the backend. key-gen is cheap, and there is about zero motivation for some heavy CA-like machinery with all of its ops and maintenance considerations to be involved at all. DKIM got that right. DANE seems to have gotten that right. Webauthn seems to gotten that right. Everything that I'm aware of goes off the rails when certs are introduced. Web/TLS is the real exception and mainly because the web grew up with it. Every other use is suspect until proven necessary, IMO.
Mike
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MWYKT67G...
On 5/20/25 10:33 AM, Tom Beecher wrote:
Nobody in their right mind would want a login user to carry around a bundle of bits on their laptop of what they are authorized to do
EKU is not 'This certificate defines what the user is allowed to do'.
It is "This certificate is valid to authenticate ONLY IF it is being presented to you in a specific context."
Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well. Mike
Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Say I run a storage unit business. When you rent a unit, I give you a code. I have decided (by my policy) that any user with a valid code can access their unit 24/7/365. You come to rent a unit from me. You ask that your code only works on Sundays, because that is the only day you will ever come. You have decided (by your policy) you want something more restrictive than mine. I agree. Someone shows up on Wednesday and tries to use your code. You told me that would never be you, so I deny the entry, because *YOU* told me not to allow it. Semantically, you could say it's 'you did not authorize' , but really it's "I did not not authenticate the identity of this user, based on verified instructions that person provided me". This is really al EKU is. I'm not arguing it's perfect. But that's what it is. On Tue, May 20, 2025 at 1:46 PM Michael Thomas <mike@mtcc.com> wrote:
On 5/20/25 10:33 AM, Tom Beecher wrote:
Nobody in their right mind would
want a login user to carry around a bundle of bits on their laptop of what they are authorized to do
EKU is not 'This certificate defines what the user is allowed to do'.
It is "This certificate is valid to authenticate ONLY IF it is being presented to you in a specific context."
Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Mike
On 5/20/25 11:12 AM, Tom Beecher wrote:
Same difference: burying policy into an authentication token. What is the point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Say I run a storage unit business. When you rent a unit, I give you a code. I have decided (by my policy) that any user with a valid code can access their unit 24/7/365.
You come to rent a unit from me. You ask that your code only works on Sundays, because that is the only day you will ever come. You have decided (by your policy) you want something more restrictive than mine. I agree.
Someone shows up on Wednesday and tries to use your code. You told me that would never be you, so I deny the entry, because *YOU* told me not to allow it. Semantically, you could say it's 'you did not authorize' , but really it's "I did not not authenticate the identity of this user, based on verified instructions that person provided me".
This is really al EKU is. I'm not arguing it's perfect. But that's what it is.
Unless you're willing to say that whatever is doing the authz/policy is *offline* -- ie, can't look that policy up in real time -- this can all be done using normal online mechanisms. That is, "server, can is this identity allowed to do this or that?" in your example. I'm not arguing that it doesn't work as stated. I'm arguing that they bring a tremendous amount of cert baggage -- business models, enrollment, revocation, etc, etc -- that is really hard to justify under any normal circumstance. Asymmetric keying unfortunately involves way too many people thinking that once they are involved, certs are necessary. It need not be, and in fact the vast majority of cases would greatly simplified to just get rid of certs entirely, even the basic name/identity binding they provide. Mike
Unless you're willing to say that whatever is doing the authz/policy is *offline* -- ie, can't look that policy up in real time -- this can all be done using normal online mechanisms. That is, "server, can is this identity allowed to do this or that?" in your example.
I'm not arguing that it doesn't work as stated. I'm arguing that they bring a tremendous amount of cert baggage -- business models, enrollment, revocation, etc, etc -- that is really hard to justify under any normal circumstance. Asymmetric keying unfortunately involves way too many people thinking that once they are involved, certs are necessary. It need not be, and in fact the vast majority of cases would greatly simplified to just get rid of certs entirely, even the basic name/identity binding they provide.
I don't entirely disagree with that perspective. Lots of merit to it. I think most of my responses have been directed towards those who seem to be *disagreeing* with the 'this is how it works" bits. On Tue, May 20, 2025 at 2:23 PM Michael Thomas <mike@mtcc.com> wrote:
On 5/20/25 11:12 AM, Tom Beecher wrote:
Same difference: burying policy into an authentication token. What is the
point? A backend presented with an authenticated identity can do the same thing far easier and far more scalable without any of the downsides like mentioned. A backend server doesn't even need a name/key binding borne by the client at all, let alone bearing policy info as well.
Say I run a storage unit business. When you rent a unit, I give you a code. I have decided (by my policy) that any user with a valid code can access their unit 24/7/365.
You come to rent a unit from me. You ask that your code only works on Sundays, because that is the only day you will ever come. You have decided (by your policy) you want something more restrictive than mine. I agree.
Someone shows up on Wednesday and tries to use your code. You told me that would never be you, so I deny the entry, because *YOU* told me not to allow it. Semantically, you could say it's 'you did not authorize' , but really it's "I did not not authenticate the identity of this user, based on verified instructions that person provided me".
This is really al EKU is. I'm not arguing it's perfect. But that's what it is.
Unless you're willing to say that whatever is doing the authz/policy is *offline* -- ie, can't look that policy up in real time -- this can all be done using normal online mechanisms. That is, "server, can is this identity allowed to do this or that?" in your example.
I'm not arguing that it doesn't work as stated. I'm arguing that they bring a tremendous amount of cert baggage -- business models, enrollment, revocation, etc, etc -- that is really hard to justify under any normal circumstance. Asymmetric keying unfortunately involves way too many people thinking that once they are involved, certs are necessary. It need not be, and in fact the vast majority of cases would greatly simplified to just get rid of certs entirely, even the basic name/identity binding they provide.
Mike
On 5/20/25 11:25 AM, Tom Beecher wrote:
Unless you're willing to say that whatever is doing the authz/policy is *offline* -- ie, can't look that policy up in real time -- this can all be done using normal online mechanisms. That is, "server, can is this identity allowed to do this or that?" in your example.
I'm not arguing that it doesn't work as stated. I'm arguing that they bring a tremendous amount of cert baggage -- business models, enrollment, revocation, etc, etc -- that is really hard to justify under any normal circumstance. Asymmetric keying unfortunately involves way too many people thinking that once they are involved, certs are necessary. It need not be, and in fact the vast majority of cases would greatly simplified to just get rid of certs entirely, even the basic name/identity binding they provide.
I don't entirely disagree with that perspective. Lots of merit to it.
I think most of my responses have been directed towards those who seem to be *disagreeing* with the 'this is how it works" bits.
Yeah, there were other parts of this thread that I didn't comment on that seemed wrong headed too (not you, iirc). Probably just as well :) Suffice it to say, I pretty much agree with Eliot's assessment of "mismash" re: authn/authz. Mike
On Tue, May 20, 2025 at 2:32 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
(SNIP) Suffice it to say, I pretty much agree with Eliot's assessment of "mismash" re: authn/authz.
This is likely due to X.509 (and various other parts of X.500 - which surprisingly I think I've only seen one other person mention in this thread so far) were historically designed to *be* AA, providing identities tied to actual structured, registered entities/objects - not simply a verification method for public keys. X.500 was also designed with the expectation of federation -- or at the least org-specific -- rather than centralization. Which is why a lot of this stuff makes more sense if you approach X.509 as an org-managed thing first and foremost, and wide-trust CAs being bolted on as kind of a kludgy ad-hoc post-facto sort of thing rather than the other way around (if private authorities are considered at all in your mental model). DAP et. al. instead gave way to LDAP and X.509 kind of got co-opted into encryption purposes instead (because static *identities*, even if they have no associated *entity* can still be useful in certain contexts when it comes to cryptographic exchange, which is why as hard as some people might try, PGP/GnuPG still isn't going anywhere -- it serves some purposes that non-attributed asym crypto can't. But I digress.) (That reminds me - Michael, Kerberos is still heavily used! Active Directory - and I guess whatever "cloud"-y thing Microsoft has now.. "Entra"? -is basically just DNS, Kerberos, and LDAP wrapped up in a clicky-clicky. FreeIPA and other F/OSS IdP/IdMs still *heavily* use Kerberos as well. It hasn't gone anywhere, it's just usually abstracted away and buried underneath a more C-level-friendly interface.) So a significant amount of KU/EKU is still kind of mired in the historical roots of X.509 and has been shoehorned into other uses. (Though if I recall correctly, id-kp-(client|server)Auth wasn't introduced until AFTER X.509 sort of branched into its own away from strict X.500 usage, but it's still within the timeframe of "yes, these certificates are idents for actual entities in an org-centric system". There's some overlap in the timeframes.) Generally speaking if you're using EKU client/server restrictions (and technically per RFC 5280, again, it should only be used for Web mTLS auth), more power to you - but to reiterate something I've said multiple times, it only makes sense *if you're running your own org-private CA*. I suspect that's why Google is requiring absence of id-kp-clientAuth for anchor inclusion - horrible abuses and misunderstanding of that particular bit seem rampant (and Let's Encrypt, nor to my knowledge any other wide-trust CA, even issues user-entity leaf certificates) because it's an RFC violation - per 4.2.1.12 of 5280: "If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." I suspect Google recognized that wide-trust CAs should not be issuing certs for usage that will be acting as a web client to *org-foreign* wide-trust-signed web servers requiring mTLS auth. Because it doesn't make sense to do so.
On 5/20/25 12:56 PM, brent saner via NANOG wrote:
On Tue, May 20, 2025 at 2:32 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
(SNIP) Suffice it to say, I pretty much agree with Eliot's assessment of "mismash" re: authn/authz.
This is likely due to X.509 (and various other parts of X.500 - which surprisingly I think I've only seen one other person mention in this thread so far) were historically designed to *be* AA, providing identities tied to actual structured, registered entities/objects - not simply a verification method for public keys.
Let's start with the obvious: X.509 is *old*. The assumptions it made are either not true anymore or just not applicable to the modern world for the most part.
X.500 was also designed with the expectation of federation -- or at the least org-specific -- rather than centralization. Which is why a lot of this stuff makes more sense if you approach X.509 as an org-managed thing first and foremost, and wide-trust CAs being bolted on as kind of a kludgy ad-hoc post-facto sort of thing rather than the other way around (if private authorities are considered at all in your mental model).
At this point in time, what X.509 was or wasn't designed to do is sort of irrelevant. It's main use -- by far -- is providing an identity to key binding which browsers with embedded CA roots can verify against. That's about it. All of the rest is pretty irrelevant in this day and age and everybody should be extremely suspicious use of certs for anything beyond that without going back to first principles of what is trying to be achieved, rather than starting from the premise of "certs are necessary, so how do we achieve XYZ with them?" Unfortunately that's the way too many of us with too much gray in our beards were encultured back in the day.
(That reminds me - Michael, Kerberos is still heavily used! Active Directory - and I guess whatever "cloud"-y thing Microsoft has now.. "Entra"? -is basically just DNS, Kerberos, and LDAP wrapped up in a clicky-clicky. FreeIPA and other F/OSS IdP/IdMs still *heavily* use Kerberos as well. It hasn't gone anywhere, it's just usually abstracted away and buried underneath a more C-level-friendly interface.)
Yes, I'm aware of that. It sort of proves my point though: Kerberos has been sort of been relegated to a fairly "niche" slice of the identity world where in the 80's it had a lot more traction especially in the .edu world back then. These days it's almost all username/password over TLS due to the web-like world we live in (and everything needs to support). Maybe webauthn will make some of the problems better, but it should be noted that even webauthn doesn't use certs for clients -- enrolling naked public to a given identity sitting in an online database is completely adequate. (I say this as somebody who likes Kerberos, but reality is still reality).
So a significant amount of KU/EKU is still kind of mired in the historical roots of X.509 and has been shoehorned into other uses. (Though if I recall correctly, id-kp-(client|server)Auth wasn't introduced until AFTER X.509 sort of branched into its own away from strict X.500 usage, but it's still within the timeframe of "yes, these certificates are idents for actual entities in an org-centric system". There's some overlap in the timeframes.)
Yeah, so let's not do that. There is an awful lot of X.509 hammers (and their vendors, especially) laying around looking for anything resembling an identity nail regardless of whether it makes any sense wrt authn/authz/policy. I've seen plenty of times where people start with the premise of "first we have an X.509 binding, and then what happens?" which instantly falls into a very deep rathole that's hard to claw back out of. The mistake is first positing the existence of an X.509 style key/name binding first -- it should be the last choice, and only if there is absolutely no other way to achieve the requirements, imo. Mike
On Tue, May 20, 2025 at 4:45 PM Michael Thomas via NANOG < nanog@lists.nanog.org> wrote:
(SNIP)
So a significant amount of KU/EKU is still kind of mired in the historical roots of X.509 and has been shoehorned into other uses. (Though if I recall correctly, id-kp-(client|server)Auth wasn't introduced until AFTER X.509 sort of branched into its own away from strict X.500 usage, but it's still within the timeframe of "yes, these certificates are idents for actual entities in an org-centric system". There's some overlap in the timeframes.)
Yeah, so let's not do that. There is an awful lot of X.509 hammers (and their vendors, especially) laying around looking for anything resembling an identity nail regardless of whether it makes any sense wrt authn/authz/policy. I've seen plenty of times where people start with the premise of "first we have an X.509 binding, and then what happens?" which instantly falls into a very deep rathole that's hard to claw back out of. The mistake is first positing the existence of an X.509 style key/name binding first -- it should be the last choice, and only if there is absolutely no other way to achieve the requirements, imo.
Yeah, this is fair. Probably the only real relevance X.509 (or... *TLS certificates* I guess we should say, since it's not really X.509 anymore) that I can think of is for LDAP entities tied to the subject (and principals, KRB tickets, etc. thereof), and those are fairly rare. Certs for HTTPS, SMTPS/SMTP+STARTTLS etc. feels more like a time-trodden "solution looking for a problem" in its implementation than vice versa.
On Tue, May 20, 2025 at 8:10 AM Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys.
Hi Jay, I /might/ want to do that, but it's still a mishmash of authentication and authorization,. While I /might/ want to do that I definitely don't want it imposed on me from on high. The CA should be authenticating my identity, not "helping" make authorization decisions. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
While I /might/ want to do that I definitely don't want it imposed on me from on high.
It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present. Who is "imposing" something on you? On Thu, May 22, 2025 at 12:29 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Tue, May 20, 2025 at 8:10 AM Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys.
Hi Jay,
I /might/ want to do that, but it's still a mishmash of authentication and authorization,. While I /might/ want to do that I definitely don't want it imposed on me from on high. The CA should be authenticating my identity, not "helping" make authorization decisions.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZCBG6UNG...
On 22.05.2025 19:44, Tom Beecher via NANOG wrote:
While I /might/ want to do that I definitely don't want it imposed on me from on high.
It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
The CA. Eliot
On Thu, May 22, 2025 at 12:29 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Tue, May 20, 2025 at 8:10 AM Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. Hi Jay,
I /might/ want to do that, but it's still a mishmash of authentication and authorization,. While I /might/ want to do that I definitely don't want it imposed on me from on high. The CA should be authenticating my identity, not "helping" make authorization decisions.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZCBG6UNG...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNNNY3SZ...
It’s not really the CAs driving this. It’s the Google Trusted Root Program. The CAs want their roots trusted by Chrome. This article has a little more background on it. https://www.ssl.com/blogs/removal-of-the-client-authentication-eku-from-tls-... On Thu, May 22, 2025 at 10:54 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
On 22.05.2025 19:44, Tom Beecher via NANOG wrote:
While I /might/ want to do that I definitely don't want it imposed on me from on high.
It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
The CA.
Eliot
On Thu, May 22, 2025 at 12:29 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:
On Tue, May 20, 2025 at 8:10 AM Jay Acuna via NANOG <nanog@lists.nanog.org> wrote:
One of the things a user /might/ want to do is have multiple Public/Secret keypairs, and compartmentalize your keys. Hi Jay,
I /might/ want to do that, but it's still a mishmash of authentication and authorization,. While I /might/ want to do that I definitely don't want it imposed on me from on high. The CA should be authenticating my identity, not "helping" make authorization decisions.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZCBG6UNG...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNNNY3SZ...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5WQYR4SV...
On Thu, May 22, 2025 at 12:45 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
want it imposed on me from on high. It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Your CA is imposing it clearly.. in this case LetsEncrypt. However, their reasoning ultimately is Google is mandating a new standard by fiat, and unilaterally to limit the declared purposes for your certificates. Although Google is one vendor and doesn't have IETF or any industry standards body in agreement to make EKU a mandatory field. Google holds a monopoly position which they can abuse to bypass all standards bodies and hold your CA hostage should they not agree to any new arbitrary standards or rules they come up with. If your CA doesn't agree to create and impose the extra restrictions on you and how you can use your certificates with other software, then Google will drop support for all LetsEncrypt certs from their browser Chrome. -- -JA
I don't disagree that Google imposing the certain conditions on the CAs isn't great, but that's a separate conversation. LetsEncrypt is no longer supporting one of the EKU options... that people have been complaining here for days shouldn't ever be used in the first place. /boggle On Thu, May 22, 2025 at 2:04 PM Jay Acuna <mysidia@gmail.com> wrote:
On Thu, May 22, 2025 at 12:45 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
want it imposed on me from on high. It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Your CA is imposing it clearly.. in this case LetsEncrypt.
However, their reasoning ultimately is Google is mandating a new standard by fiat, and unilaterally to limit the declared purposes for your certificates.
Although Google is one vendor and doesn't have IETF or any industry standards body in agreement to make EKU a mandatory field. Google holds a monopoly position which they can abuse to bypass all standards bodies and hold your CA hostage should they not agree to any new arbitrary standards or rules they come up with.
If your CA doesn't agree to create and impose the extra restrictions on you and how you can use your certificates with other software, then Google will drop support for all LetsEncrypt certs from their browser Chrome.
-- -JA
We use EKU to provide mTLS between components owned and run by other entities, it is not truly authentication, as we have other methods to do that but it does "keep the lumps out". For sure the industry has overloaded the "server cert" CA with other use cases, and this is why we really do need a IETF/IANA type governance and discussion, rather than what we have here with Google dictating the use cases and solution with Web blinkers. What I fear here is the other options which are two fold and ugly, so I propose option 3. 1) In software make server certs work as client certs - Which results in special code and fractured solutions 2) Create a shadow CA infra for non browser use cases - Which results in fragmented CA (yuck!) 3) Get together as an industry and push a little back and make EKU non default and only issued if asked for, which interestingly is how we have Google issue our certs right now If this is interesting to others perhaps we can discuss at the next in person NANOG. Colin On 5/22/2025 11:04:54 AM, Jay Acuna via NANOG <nanog@lists.nanog.org> wrote: On Thu, May 22, 2025 at 12:45 PM Tom Beecher via NANOG wrote:
want it imposed on me from on high. It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Your CA is imposing it clearly.. in this case LetsEncrypt. However, their reasoning ultimately is Google is mandating a new standard by fiat, and unilaterally to limit the declared purposes for your certificates. Although Google is one vendor and doesn't have IETF or any industry standards body in agreement to make EKU a mandatory field. Google holds a monopoly position which they can abuse to bypass all standards bodies and hold your CA hostage should they not agree to any new arbitrary standards or rules they come up with. If your CA doesn't agree to create and impose the extra restrictions on you and how you can use your certificates with other software, then Google will drop support for all LetsEncrypt certs from their browser Chrome. -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZNVKSJHY... [f5f1ef8a-e3e2-4162-a6ed-a98893f440d3]
It appears that Colin Constable via NANOG <nanog@lists.nanog.org> said:
We use EKU to provide mTLS between components owned and run by other entities, it is not truly authentication, as we have other methods to do that but it does "keep the lumps out".
If the entities know who each other are, why do you and they need a public CA?
2) Create a shadow CA infra for non browser use cases - Which results in fragmented CA (yuck!)
It is my impression that the normal way to manage client certs is for the organization that runs the servers to sign and distribute certs to the clients. This isn't new. R's, John
On Thu, May 22, 2025 at 2:58 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
It is my impression that the normal way to manage client certs is for the organization that runs the servers to sign and distribute certs to the clients. This isn't new.
Small private CAs per organization are perfect when the same organization runs both client and server; such as client certificates for EAP-TLS with 802.1X wireless auth. Software designed for client auth scenarios does not trust random certificates from a public CA. The cert has to allow the appropriate EKUs, but also it must be manually mapped to the active directory user by an admin, or be signed by a specific CA which is configured on the server. This does not work for applications where the client authentication is between servers at different organizations. Such as the SMTP server or Web server which wishes to connect to another company's SMTP server or Web server using mutual TLS to verify the web server FQDN for authentication to send mail or access an API endpoint as that server's identiy. Companies are not going to add a million other companies' private CAs to their system trust roots list. For the SMTP to SMTP transport associations the two organizations may barely know each other. And the whole purpose of the public CAs is to help establish server authenticity for these kind of scenarios.
R's, John -JA
On Thu, 22 May 2025, Jay Acuna wrote:
This does not work for applications where the client authentication is between servers at different organizations. Such as the SMTP server or Web server which wishes to connect to another company's SMTP server or Web server using mutual TLS to verify the web server FQDN for authentication to send mail or access an API endpoint as that server's identiy.
This is sounding awfully hypothetical. I have seen a lot of SMTP software and I have never, ever, seen one send a client certificate in an SMTP session. Submission clients sometimes use them, but that's different, and the client cert is provided by whoever runs the server. Mail servers either check the client's IP address with SPF, which works poorly for a variety of reasons, or there's a DKIM signature in the message the client sends, unrelated to the SMTP transport. R's, John PS: in the IETF we are nearly done with a long overdue update to RFC 5321 and I can assure you there is not a whiff of client certs there either.
It's not that hypothetical. I bring to your attention draft-halen-fedae <https://datatracker.ietf.org/doc/draft-halen-fedae/>, which has been deployed in Sweden to create trust within a federation of private CAs. But it's not sufficient for non-federated or non-prearranged use cases. This draft focuses on m2m, and specifically excludes web-based transaction, because the security analysis required for browser interactions is a hard problem. Creating multiple public hierarchies due to EKUs is a huge effort for what precise security benefit? I'd really like someone from Google to answer that question. Eliot On 22.05.2025 23:21, John R. Levine via NANOG wrote:
On Thu, 22 May 2025, Jay Acuna wrote:
This does not work for applications where the client authentication is between servers at different organizations. Such as the SMTP server or Web server which wishes to connect to another company's SMTP server or Web server using mutual TLS to verify the web server FQDN for authentication to send mail or access an API endpoint as that server's identiy.
This is sounding awfully hypothetical. I have seen a lot of SMTP software and I have never, ever, seen one send a client certificate in an SMTP session. Submission clients sometimes use them, but that's different, and the client cert is provided by whoever runs the server.
Mail servers either check the client's IP address with SPF, which works poorly for a variety of reasons, or there's a DKIM signature in the message the client sends, unrelated to the SMTP transport.
R's, John
PS: in the IETF we are nearly done with a long overdue update to RFC 5321 and I can assure you there is not a whiff of client certs there either. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FS3UXBW4...
On Fri, 23 May 2025, Eliot Lear wrote:
It's not that hypothetical. I bring to your attention draft-halen-fedae <https://datatracker.ietf.org/doc/draft-halen-fedae/>, which has been deployed in Sweden to create trust within a federation of private CAs. But it's not sufficient for non-federated or non-prearranged use cases. This draft focuses on m2m, and specifically excludes web-based transaction, because the security analysis required for browser interactions is a hard problem.
I'm having trouble coming up with plausible scenarios where the only thing you know about a client is that some CA said their domain is OK. Federated private CAs implement business relationships among the organizatiosns. Some random person saying "hi, I am foo.bar.com" provides what? I don't get it. I suppose there's the model PHB proposed, where it's sort of a mutant OpenID, but domains don't seem like the right level of granularity. Also, after two decades, OpenID hasn't exactly been a stunning success. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 23.05.2025 17:08, John R. Levine wrote:
Federated private CAs implement business relationships among the organizatiosns. Some random person saying "hi, I am foo.bar.com" provides what? I don't get it.
You get the same thing you get from a domain name plus possibly one additional piece of information: signer information It would seem to me that having some external attestation about the SMTP server would eliminate some amount of SMTP via BGP hijacking, but as this isn't my day job, I'm not going to make any strong claims. Eliot
On 5/23/25 10:08 AM, John R. Levine via NANOG wrote:
I'm having trouble coming up with plausible scenarios where the only thing you know about a client is that some CA said their domain is OK.
You don't know that a client is ok. What you do know is that a CA said that the entity with the certificate and corresponding key is a stated identity; e.g. the subject. Look at Kerberos, the KDC doesn't say anything other than the ticket holder has proven their identity to the KDC, ostensibly with username & password or something stronger. The Kerberized server uses the ticket that the client provided it as verification of identity from the common trusted source; the KDC. None of Kerberos, usernames & passwords, TLS client certificates actually say anything about the credentials not being compromised. They state / demonstrate that the entity using said ticket, U&P, cert have access to the necessary knowledge / data to validate as the claimed identity. Similar to how HTTPS only speaks to the connection to the server being encrypted, and nothing about the safety of visiting the site. -- Grant. . . .
On Fri, May 23, 2025 at 2:48 AM Eliot Lear <lear@lear.ch> wrote:
It's not that hypothetical. I bring to your attention draft-halen-fedae, which has been deployed in Sweden to create trust within a federation of private CAs.
Using a client TLS cert with SMTP is an option within the TLS protocol, and some clients do. Some servers may expect to verify this client cert. I have already seen non-theoretical cases where some internet domain refuses all non-TLS SMTP traffic at their MX hosts by design; they may in addition consider traffic with fully valid mutual TLS differently. Mail servers can take into account whether a valid client cert was presented during an incoming TLS connection as one of many factors which affects herustic spam filter scores. Even when a failure is not considered as equal to a SPF fail or hard drop. You can also look at Office 365 and Certificate-based connectors often used in Hybrid deployments with Microsoft Exchange. Cert-based connectors are especially required for cases where you can't know or guarantee what the IP address of the SMTP client will be beforehand. For example your on-premise environment has a dynamic IP address. You require a cert-based connector to authenticate your On-premise server's access to route mail to outside domains through the 365 service's public SMTP relay hosts which rely on mTLS for authentication. When your SMTP client connects to their public relay servers; a client certificate is presented at the TLS helo. As far as I know Microsoft does not allow you to import any actual certificates into their servers. Neither do you have options of using your own private PKI; the config involves setting details to match the certificate. The cert has to be signed by a CA and contain specified domain names belonging to your org in the subjectAltNames in order to verify your authority over the domains for public relay (Sending email to their public SMTP relay servers which has a Rcpt To: address outside of your organization). -- -JA
On Fri, 23 May 2025, Jay Acuna wrote:
Using a client TLS cert with SMTP is an option within the TLS protocol, and some clients do.
No, that was a misreading of a decades old file in the sendmail distro. As anyone who rus a mail server knows, in fact SMTP clients do not send certificates (not to be confused with submission, which is not SMTP, where a few systems do use privately signed client certs.) I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them. R's, John
"John R. Levine via NANOG" <nanog@lists.nanog.org> writes:
On Fri, 23 May 2025, Jay Acuna wrote:
Using a client TLS cert with SMTP is an option within the TLS protocol, and some clients do.
No, that was a misreading of a decades old file in the sendmail distro.
As anyone who rus a mail server knows, in fact SMTP clients do not send certificates (not to be confused with submission, which is not SMTP, where a few systems do use privately signed client certs.)
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them.
I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful. Having optional authentication on port 25 doesn't mean that arbitrary MTAs contacting your MX will be asked to authenticate. It just means that friendly clients are allowed to authenticate, and may get special treatment if they do. Typically being allowed to use the smtp server as a smarthost, similar to what you'd expect on the submission port. I for one use client certificate authentication on ports 25, 465 and 587. There is also the sendmail accessdb support for client certificates. Note that this is different from doing "AUTH EXTERNAL". It doesn't result in an authenticated username. It's more like access list rules, where you match on subject and/or issuer instead of the client IP. Such rules can be used to e.g allow relaying for specific hosts. It is fully possible to use Let's Encrypt, or other public CA, certificates here without compromising the server, provided the rules use specific certificate subjects. I guess that accessdb functionality might break with the announced change. But it's probably for the best. If you have that kind of configuration and add EXTERNAL as a trusted authentication mechanism, then anyone will be able to authenticate. This is a valid reason to remove the client bit from public CA issued server certificates. Makes it harder to make such mistakes. A private CA will always be a better choice for client certificates, even if you just use the accessdb feature. Bjørn
It appears that Bjørn Mork via NANOG <nanog@lists.nanog.org> said:
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them.
I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful.
If the client authenticates it's submission. If it doesn't, it's SMTP unless the client later authenticates with SMTP AUTH.
Having optional authentication on port 25 doesn't mean that arbitrary MTAs contacting your MX will be asked to authenticate. It just means that friendly clients are allowed to authenticate, and may get special treatment if they do. Typically being allowed to use the smtp server as a smarthost, similar to what you'd expect on the submission port.
Right, that's submission, not SMTP.
I for one use client certificate authentication on ports 25, 465 and 587.
Right, that's still submission.
There is also the sendmail accessdb support for client certificates. Note that this is different from doing "AUTH EXTERNAL". It doesn't result in an authenticated username. It's more like access list rules, where you match on subject and/or issuer instead of the client IP. Such rules can be used to e.g allow relaying for specific hosts.
Right, that's another form of submission. I think we agree that if you can only use privately signed certs in that context, it's no great loss. R's, John PS: For anyone who hasn't been following along, Postfix and Exim are a lot more popular than sendmail these days. Sendmail is more interesting as an historical artifact.
On Fri, May 23, 2025 at 12:34 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
It appears that Bjørn Mork via NANOG <nanog@lists.nanog.org> said:
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them.
I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful.
If the client authenticates it's submission. If it doesn't, it's SMTP unless the client later authenticates with SMTP AUTH.
Hi John, Only traffic on port 587 is explicitly SMTP submission.. On port 25 it might or might not be depending on how the client and server choose to use the authentication. For example, an MSA can add or change message-id, date and sender headers in the message body while an MTA is not supposed to. This happens independent of whether the connection to the MTA/MSA is authenticated. Practically speaking, there aren't a lot of applications for client certificate authenticated SMTP which aren't mail submission. But 99% is not 100% and it's an error to treat it as if it is. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 5/23/25 1:11 PM, William Herrin via NANOG wrote:
On Fri, May 23, 2025 at 12:34 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
It appears that Bjørn Mork via NANOG <nanog@lists.nanog.org> said:
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them. I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful. If the client authenticates it's submission. If it doesn't, it's SMTP unless the client later authenticates with SMTP AUTH. Hi John,
Only traffic on port 587 is explicitly SMTP submission.. On port 25 it might or might not be depending on how the client and server choose to use the authentication. For example, an MSA can add or change message-id, date and sender headers in the message body while an MTA is not supposed to. This happens independent of whether the connection to the MTA/MSA is authenticated.
Practically speaking, there aren't a lot of applications for client certificate authenticated SMTP which aren't mail submission. But 99% is not 100% and it's an error to treat it as if it is.
Plus bakes in the general practice of "hard on the outside, soft on the inside" which is a bogus thing to bake in. If downstream MTAs want client TLS auth, that's their business. Will that likely work inter-domain? No, but MTA->MTA SMTP conversations are not necessarily inter-domain. Mike
It appears that William Herrin via NANOG <nanog@lists.nanog.org> said:
On Fri, May 23, 2025 at 12:34 PM John Levine via NANOG <nanog@lists.nanog.org> wrote:
It appears that Bjørn Mork via NANOG <nanog@lists.nanog.org> said:
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them.
I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful.
If the client authenticates it's submission. If it doesn't, it's SMTP unless the client later authenticates with SMTP AUTH.
Hi John,
Only traffic on port 587 is explicitly SMTP submission.. On port 25 it might or might not be depending on how the client and server choose to use the authentication. For example, an MSA can add or change message-id, date and sender headers in the message body while an MTA is not supposed to. This happens independent of whether the connection to the MTA/MSA is authenticated.
This is a waste of time. If people want to believe that SMTP clients send certificates, there's not much I can do to persuade them otherwise. But in any event, I hope we have established that the number of people affected by the LE change to stop signing client certs rounds to zero. R's, John
John Levine via NANOG <nanog@lists.nanog.org> writes:
This is a waste of time. If people want to believe that SMTP clients send certificates, there's not much I can do to persuade them otherwise.
Let's just disagree then. But when my secondary MX receives an email and later forwards it to my primary MX over a mTLS channel, then I call that SMTP. If you want to call it submission because the secondary MX operates as an authenticated client, then fine.
But in any event, I hope we have established that the number of people affected by the LE change to stop signing client certs rounds to zero.
Sure. Bjørn
The arguments from Google about separate hierarchies is discussed. bit here, https://googlechrome.github.io/chromerootprogram/moving-forward-together/ See "Understanding dedicated hierarchies" section. On Fri, May 23, 2025 at 12:49 AM Eliot Lear via NANOG <nanog@lists.nanog.org> wrote:
It's not that hypothetical. I bring to your attention draft-halen-fedae <https://datatracker.ietf.org/doc/draft-halen-fedae/>, which has been deployed in Sweden to create trust within a federation of private CAs. But it's not sufficient for non-federated or non-prearranged use cases. This draft focuses on m2m, and specifically excludes web-based transaction, because the security analysis required for browser interactions is a hard problem.
Creating multiple public hierarchies due to EKUs is a huge effort for what precise security benefit? I'd really like someone from Google to answer that question.
Eliot
On 22.05.2025 23:21, John R. Levine via NANOG wrote:
On Thu, 22 May 2025, Jay Acuna wrote:
This does not work for applications where the client authentication is between servers at different organizations. Such as the SMTP server or Web server which wishes to connect to another company's SMTP server or Web server using mutual TLS to verify the web server FQDN for authentication to send mail or access an API endpoint as that server's identiy.
This is sounding awfully hypothetical. I have seen a lot of SMTP software and I have never, ever, seen one send a client certificate in an SMTP session. Submission clients sometimes use them, but that's different, and the client cert is provided by whoever runs the server.
Mail servers either check the client's IP address with SPF, which works poorly for a variety of reasons, or there's a DKIM signature in the message the client sends, unrelated to the SMTP transport.
R's, John
PS: in the IETF we are nearly done with a long overdue update to RFC 5321 and I can assure you there is not a whiff of client certs there either. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FS3UXBW4...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KT3Q4C62...
On 5/22/25 2:58 PM, John Levine via NANOG wrote:
If the entities know who each other are, why do you and they need a public CA?
Occam's Razor / Parsimony.
It is my impression that the normal way to manage client certs is for the organization that runs the servers to sign and distribute certs to the clients. This isn't new.
If you have multiple servers on the Internet that MUST use a public CA for various unassociated clients to trust the certificate and you want to leverage a certificate for communications between the two servers, then Occam's Razor / Parsimony would state that you use the simpler / one solution. Solution 1 is to have and re-use the existing certificates that you must have from a single public CA. Solution 2 is to have and use two separate certificate & key pairs, each from a different CA, one public and the other private. -- Grant. . . .
It appears that Grant Taylor via NANOG <nanog@lists.nanog.org> said:
It is my impression that the normal way to manage client certs is for the organization that runs the servers to sign and distribute certs to the clients. This isn't new.
If you have multiple servers on the Internet that MUST use a public CA for various unassociated clients to trust the certificate and you want to leverage a certificate for communications between the two servers, then Occam's Razor / Parsimony would state that you use the simpler / one solution. ....
I would have thought this was obvious but apparently not: The point of a private CA is that you know the people whose certificates you're signing. If I run a mail system, I only sign the certs for my own users and I check who they are before signing. When someone presents a certificate, that cert includes not only the identity of the certificate itself, but also of the signer(s). So in my mail system, when a mail client presents a cert, if I see that my signature is on it I know it's one of my users. Even better, I can trust the identity info in the cert because I know I checked it when I signed it. And even better than that, I can sign whatever I want so the identity can include an email address or other user identity, not just a domain. Needless to say, random public CAs don't do that. A few of them used to sign mail address certs for S/MIME but none do now (at least not for free), and anyway if it doesn't have my private CA's signature, I don't know if it's one of my users or not. The security model for TLS always assumed that different signers would sign different things for different reasons. If you're using DANE to check your certs, for example, the TLSA record can have usage 3 to match the cert's own domain, or usage 0 to match the CA so you can use the TLSA record to validate everything you signed. It's a failure of the model that for too many purposes there's a big blob of public CAs which make only cursory identity checks and all of which are considered equivalent. R's, John
On 5/23/25 8:53 PM, John Levine via NANOG wrote:
The point of a private CA is that you know the people whose certificates you're signing.
Yes, it is obvious that is the point of a private CA. But you seem to have misunderstood my (non-hypothetical) example. Consider a web server that is serving up web pages to random people on the Internet completely unaffiliated / unassociated / unknown to the server; e.g. to you and your family. To be able to serve pages over HTTPS to them, a TLS certificate from a public CA that they trust MUST be used. Now assume, for the sake of discussion, that you have multiple such servers and they want to use mTLS to authenticate their identities to each other. -- Maybe it's for SMTP, or IKE, or VoIP, or.... Solution 1 is to re-use the existing TLS certificate & key that they already have for mTLS. Solution 2 is to have separate certificates used for mTLS. You seem to be advocating for solution 2 with the added complexity of a private CA. Solution 2 (or worse if private CA) involves additional configuration, additional complexity, additional certificates & keys to secure, and additional things to break. People are often advised to avoid running their own private CA for some good security reasons. So I maintain that Occam's Razor / Parsimony suggest that solution 1 be used as it's both simpler and has fewer components. -- Grant. . . .
It appears that Grant Taylor via NANOG <nanog@lists.nanog.org> said:
Consider a web server that is serving up web pages to random people on the Internet completely unaffiliated / unassociated / unknown to the server; e.g. to you and your family. To be able to serve pages over HTTPS to them, a TLS certificate from a public CA that they trust MUST be used.
Now assume, for the sake of discussion, that you have multiple such servers and they want to use mTLS to authenticate their identities to each other. -- Maybe it's for SMTP, or IKE, or VoIP, or....
As someone else noted, in this utterly implausible scenario (nobody uses domain certificates to authorize mail submission, and SMTP doesn't use client certs at all) you would have your private CA sign the certs for your users. You do know that you can have multiple signatures on the same cert, don't you? R"s, John
On 5/23/25 9:38 PM, John Levine via NANOG wrote:
As someone else noted, in this utterly implausible scenario
I'll give you implausible or unlikely or rare. Maybe even rare enough to be effectively nobody.
(nobody uses domain certificates to authorize mail submission,
But I will not give you actual nobody. I know multiple other people that use their server's TLS certificate from a public CA for mTLS to authorize submission. Your statement that nobody uses domain certificates to authorize mail submission, as in zero people, is wrong. The certificates in question are for the system's FQDN.
and SMTP doesn't use client certs at all)
In order to avoid SMTP (server receiving email) vs submission (server relaying email) I'll say this: I know of multiple MTAs that are using their cert for their FQDN to authenticate to other servers while relaying email. The first / relaying server is using it's TLS certificate for mTLS with the next server in line.
you would have your private CA sign the certs for your users.
You seem to be thinking / talking about people in front of keyboards / smart devices. I'm talking about /servers/; NS1, NS2, and FS1, not people, using mTLS to authenticate to MTA1.
You do know that you can have multiple signatures on the same cert, don't you?
Yes, I'm well aware of that. What I'm not aware of is how different signers have to do with extended key usage options. -- My understanding is that the EKU options are requested in the CSR and approved EKU options are propagated to the signed cert. But a single cert signed by multiple signers would still have the same EKU options. -- Grant. . . .
Once upon a time, Grant Taylor via NANOG <nanog@lists.nanog.org> said:
Solution 2 (or worse if private CA) involves additional configuration, additional complexity, additional certificates & keys to secure, and additional things to break.
If you have such a complicated multi-server setup that includes a need to encrypt your internal traffic, you should definitely be using some configuration management system to make sure you have all the encryption set correctly... at which point another cert is a trivial amount of effort. -- Chris Adams <cma@cmadams.net>
On 5/23/25 9:48 PM, Chris Adams via NANOG wrote:
If you have such a complicated multi-server setup that includes a need to encrypt your internal traffic, you should definitely be using some configuration management system to make sure you have all the encryption set correctly
The tooling used (or not) is orthogonal to the discussion at hand.
at which point another cert is a trivial amount of effort.
The tooling doesn't alter the need for a second certificate & key. Nor does the tooling speak to the added complexity / risks of a private CA. Sometimes multi-server can be as few as two or three servers. And there's no guarantee that they are the same OS or otherwise use the same configuration. So ... configuration management becomes even more overhead. -- Grant. . . .
On Fri, May 23, 2025, 21:14 Grant Taylor via NANOG <nanog@lists.nanog.org> wrote:
(SNIP)
If you have multiple servers on the Internet that MUST use a public CA for various unassociated clients to trust the certificate and you want to leverage a certificate for communications between the two servers, then Occam's Razor / Parsimony would state that you use the simpler / one solution.
Solution 1 is to have and re-use the existing certificates that you must have from a single public CA.
Mixing public and private communication under a single resource is poor practice. Using a public CA as a trust authority for private resources using mTLS auth offers no segregation nor least-access and relies wholly on individual identity checking. Better hope you didn't typo that regex!
Solution 2 is to have and use two separate certificate & key pairs, each from a different CA, one public and the other private.
Technically they *can* have the same private key... the CA just signs a CSR generated by a key. BUT that aside, this is the objectively correct approach. Under no circumstance should one use a public CA for verifying client certificates. Occam's Razor is for explaining phenomena. Taking the simplest approach for *security design* with no regard for ramifications has a different term applied: "lazy"[0]. [0] Or "low-hanging fruit", depending on if you're blue or red I suppose.
It's not obvious whether Google can afford to drop LetsEncrypt, the single most widely used CA, used on approx 2/3 of all websites, over a unilateral policy decision by Google. It would amount to Google blocking 2/3 of the web in Chrome. Users would be forced to roll back the version or switch to different browsers. However, it's obvious that Let's Encrypt isn't interested in taking that risk. On 22/05/25 20:03, Jay Acuna via NANOG wrote:
On Thu, May 22, 2025 at 12:45 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
want it imposed on me from on high. It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present. Who is "imposing" something on you? Your CA is imposing it clearly.. in this case LetsEncrypt.
However, their reasoning ultimately is Google is mandating a new standard by fiat, and unilaterally to limit the declared purposes for your certificates.
Although Google is one vendor and doesn't have IETF or any industry standards body in agreement to make EKU a mandatory field. Google holds a monopoly position which they can abuse to bypass all standards bodies and hold your CA hostage should they not agree to any new arbitrary standards or rules they come up with.
If your CA doesn't agree to create and impose the extra restrictions on you and how you can use your certificates with other software, then Google will drop support for all LetsEncrypt certs from their browser Chrome.
-- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZNVKSJHY...
On Fri, May 23, 2025 at 8:35 AM nanog--- via NANOG <nanog@lists.nanog.org> wrote:
It's not obvious whether Google can afford to drop LetsEncrypt, the single most widely used CA, used on approx 2/3 of all websites, over a unilateral policy decision by Google. It would amount to Google blocking 2/3 of the web in Chrome. Users would be forced to roll back the version or switch to different browsers.
However, it's obvious that Let's Encrypt isn't interested in taking that risk.
Google is one of the top sponsors for Let's Encrypt. Lot of money. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Thu, May 22, 2025 at 10:44 AM Tom Beecher <beecher@beecher.cc> wrote:
While I /might/ want to do that I definitely don't want it imposed on me from on high.
It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Google and Letsencrypt, as discussed in the message which started this thread. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Google and Letsencrypt, as discussed in the message which started this thread.
So let me get this straight. 1. You have just spent multiple days arguing that EKU options in X.509 certificates is not something that should be used at all because (in your view) it is an authorization function. Even in your last message you say this : The CA should be authenticating my
identity, not "helping" make authorization decisions.
2. LetsEncrypt is making a change to REMOVE one of the possible EKU options, that you believe shouldn't be used in the first place. 3. You interpret this as having something 'imposed' on you. On Thu, May 22, 2025 at 2:09 PM William Herrin <bill@herrin.us> wrote:
On Thu, May 22, 2025 at 10:44 AM Tom Beecher <beecher@beecher.cc> wrote:
While I /might/ want to do that I definitely don't want it imposed on me from on high.
It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Google and Letsencrypt, as discussed in the message which started this thread.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Thu, May 22, 2025 at 11:27 AM Tom Beecher <beecher@beecher.cc> wrote:
Google and Letsencrypt, as discussed in the message which started this thread.
So let me get this straight.
Hi Tom, I wouldn't say you have it straight, but you have the basic facts. In my opinion, EKUs should not exist because they corrupt the authentication-authorization process by placing an authorization component in the authentication step. Since they do exist, despite my displeasure, letsencrypt was doing the right thing by including both compatible EKUs in the certificates they issue, making their existence moot. Per the press release, they will cease doing the right thing. Per the press release, they will cease doing the right thing because Google insisted and threatened to make their certificates stop working if they didn't. That is an imposition, and it's from Google who is about as "on high" as it gets without being an actual government. This imposition is possible because the base technology improperly mixed authentication and authorization components instead of keeping the boundary between the two clean. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Thu, May 22, 2025 at 1:28 PM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
So let me get this straight. 1. You have just spent multiple days arguing that EKU options in X.509 certificates is not something that should be used at all because (in your .. 2. LetsEncrypt is making a change to REMOVE one of the possible EKU .. 3. You interpret this as having something 'imposed' on you.
Yes. To use network routers as an analogy to what the CA is doing: In network terms: 1 Your router vendor should not ship you internet routers with an Access-list (EKU) imposed upon your equipment's network interfaces' traffic forwarding capabilities without your request and approval as the subject/owner of the machine (Owner of the cert whose identity the CA exists to attest to). 2 LetsEncrypt originally issues you certificates you applied to authenticate your identity with no EKU, or a less-restrictive EKU. In network terms: Your router vendor ships your equipment that has no default access list imposed, so at least you can decide the policy locally, Or at least contains permit ip any any 3. LetsEncrypt's change is to start enforcing that you can only get certificates with an EKU and it must be a more restrictive EKU. You will only be allowed to forward packets compliant with that more restrictive EKU, and the EKU signals other parties to drop packets from you which don't comply. In network terms; Your hardware vendor's change of policy is to start enforcing a new access-list on all IP interfaces that says "permit tcp any any" deny any" With no approval or option for the subject of the cert to remove or revise the declared restriction. There may be some protocols you are using which are no longer allowed such ICMP, but your vendor does not think a significant number of people use ICMP so they don't care you would not be able to get routers approved by them to forward that protocol anymore. -- -JA
brent saner via NANOG <nanog@lists.nanog.org> writes:
On Sat, May 17, 2025, 19:34 William Herrin via NANOG <nanog@lists.nanog.org> wrote:
Does seem like it might have an impact on SMTP...
SMTPS/SMTP + STARTTLS for MTA <-> MTA does not use id-kp-clientAuth EKU, which is what they're deprecating/removing. Certs are used on MTAs for *identity verification of the server* and *integrity validation/encryption*, not authentication.
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).
The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate. 99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
maybe this answers my questions. I am not sure. Is there any clear documenation of what is going on here?
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HV65MB3D...
-- Christian de Larrinaga
Is there any clear documenation of what is going on here?
Yes. LE's announcement : https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ Chromium Root Program Participation Policies, v1.6, Sec2 : https://googlechrome.github.io/chromerootprogram/#2-chrome-root-program-part... To continue to be a Root CA in the Chrome Root Store, CA's must abide by the new requirements,which for this convo is : - focused only on the specific PKI use case of issuing TLS server authentication certificates to websites. Most things , especially in a browser, are going to be doing 'normal' ( 1-way ) TLS, meaning only the server identity is verified. It is also possible to implement mutual TLS (mTLS) which the client and server must both verify their identities. This is where TLS client authentication certs are used. Most people aren't doing mTLS for a variety of reasons, and if you are, you're not relying on a public CA to do it anyways. On Mon, May 19, 2025 at 6:49 AM Christian de Larrinaga via NANOG < nanog@lists.nanog.org> wrote:
brent saner via NANOG <nanog@lists.nanog.org> writes:
On Sat, May 17, 2025, 19:34 William Herrin via NANOG < nanog@lists.nanog.org> wrote:
Does seem like it might have an impact on SMTP...
SMTPS/SMTP + STARTTLS for MTA <-> MTA does not use id-kp-clientAuth EKU, which is what they're deprecating/removing. Certs are used on MTAs for *identity verification of the server* and *integrity validation/encryption*, not authentication.
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).
The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate. 99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
maybe this answers my questions. I am not sure.
Is there any clear documenation of what is going on here?
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HV65MB3D...
-- Christian de Larrinaga _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/F5UVFTDK...
On Mon, May 19, 2025 at 6:54 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Most things , especially in a browser, are going to be doing 'normal' ( 1-way ) TLS, meaning only the server identity is verified. It is also possible to implement mutual TLS (mTLS) which the client and server must both verify their identities. This is where TLS client authentication certs
Yes. And Mutual TLS is also common. For example: A Web farm's frontend load balancer consists of a Reverse proxy server that perform only ServerAuth for traffic between end users' web browser and the reverse proxy server. For each HTTPS request: the reverse proxy server accepts the user's HTTPS connection and opens an outgoing HTTPS connection to the true web server in parallel in order to service the end user's request. The outgoing HTTPS connections made from the reverse proxy server towards the pool of true web servers should be mutual TLS-required HTTPS connections. The load balancer/reverse proxy has the TLS certificate signed by LetsEncrypt which is used for Server authentication when accepting an incoming HTTPS connection from a browser, and the same certificate is used for ClientAuth when the reverse proxy server connects to the True web server at the backend. The "true" web servers which the reverse proxy forwards to contain a configuration which specifies that Client authentication is required to connect; the Client certificate must be signed by a trusted CA derived from the Public trusted CA roots list, and the CN on that certificate must match the Proxy server's CN. This allows the web servers to confirm that the HTTPS requests comes from the legitimate load balancer IP. This prevents attempts to probe or attempt to crawl backend servers directly; in case nefarious actors discover the true web servers' IP address in attempt to bypass the load balancer's controls or filtering policies - they will be unable to negotiate a HTTPS connection. This also confirms at a protocol level some phisher or other adversary in the middle has not inserted themselves into the transaction as an unauthorized reverse proxy. ClientAuth and ServerAuth in this regard is about validating the identity of network endpoints; clients and servers which have a FQDN. TLS validation is unrelated to user authentication or authorization. -- -JA
It appears that Christian de Larrinaga via NANOG <nanog@lists.nanog.org> said:
The only case this would matter is if you are using an MUA/sender/client *authenticating* to an MTA with a certificate. 99.999% of email is one-way server TLS, not mTLS. LE certs will continue to work fine for SMTP.
maybe this answers my questions. I am not sure.
Is there any clear documenation of what is going on here?
Does this mail system connect to some other smarthost, and log into the smarthost using that certificate rather than a username and password? If it's not doing that, and it sure doesn't sound like it is, you're fine. R's, John
participants (19)
-
Bjørn Mork -
brent saner -
Chris Adams -
Christian de Larrinaga -
Colin Constable -
Crist Clark -
Eliot Lear -
Elmar K. Bins -
Grant Taylor -
Jay Acuna -
John Levine -
John R. Levine
-
Michael Thomas -
michael.greenup＠ionos.com -
nanog＠immibis.com -
Randy Bush -
Tom Beecher -
Tom Ivar Helbekkmo -
William Herrin