Klaus, This is a warning to you that you are in violation of the mailing list procedures; please review the monthly reminder prior to posting again - see [1]. Please keep it professional; there is no need for profanity. If you have question about this warning please feel free to contact the chairs via tls-cha...@ietf.org <mailto:tls-cha...@ietf.org>.
The Chairs, Deirdre, Joe, and Sean [1] https://mailarchive.ietf.org/arch/msg/tls/y43AU-EqBvKcd1us8Dzs4VtgJ4A/ > On Jun 18, 2025, at 18:46, Klaus Frank > <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org> wrote: > > On 2025-06-17 20:16:19, David Benjamin wrote: >> (As always, wearing an individual hat here. In particular, I am *not* >> speaking on behalf of the Chrome Root Program.) >> >> This draft is not the way to solve this problem. >> >> The point of markers like EKUs is to avoid cross-protocol attacks. Client >> and server here do not refer to abstract classifications of entities. They >> are specific, well-defined roles in the TLS protocol. Whether the TLS >> client represents a human or a backend service, it is a client as far as >> TLS is concerned. This draft breaks this. TLS stacks that implement it risk >> cross-protocol attacks. > > I thought I was only re-aligning with your interpretation of a client being a > end-device? Considering all of the discussions regarding this topic the > common theme appears to be you at the Chromium project (and CAs that started > to follow your policy change) ONLY considering clientAuth being used for end > user authentication like with smart cards. server-to-server was overlooked > everywhere. And within the discussions to this topic way too much was spent > on trying to point out that a TLS-client is the initiator of a TLS connection > and not an device held by and enduser. > > Frankly if there is no way to get a clientAuth certificate for a server to be > used in a similar way like a server certificate and the understanding at the > CA-level appears to be "server means device" and "client means end-user" then > the only logical step is to re-align the definition within the RFCs to > unbreak all of these usecases. > > At least to me that is a way better approach than just disabling TLS > validation entirely. Which is basically what people will be forced to do. > Changing the protocols takes time. "Just" allowing a server-cert to be > considered valid by a TLS-server that is expecting to be communicating in a > P2P-fashing within a decentralized network only with other server and never > with end users is way better. It also allows you at Chromium to just not care > about them at all as this special kind of validation would be limited to > software expecting server-to-server connections only. > > Also it shouldn't cause any additional impact. As the required assurances are > the ones being provided "there is a server with this dns name or ip address". > > And regarding the cross-protocol attack part, well if the only commonly > trusted certificates are of EKU serverAuth then that is basically the only > EKU in existance. Everything else may as well not exist at all at that point > as it will fail validation anyway. > >> As for PKI hierarchies, the Web PKI, as curated by web clients, >> authenticates web servers. All the policies and expectations around it, >> from monitoring to domain validation to Certificate Transparency, are >> maintained with web servers in mind. This blog discusses some of this: >> https://blog.mozilla.org/security/2021/05/10/beware-of-applications-misusing-root-stores/ > I understand your thought process. However that still doesn't change the > reality that it is basically the **only** PKI hierarchie in existance. > > It would be a different thing if not literally everything in existance would > share the Web-PKI browsers use. > >> That is not to say that backend services shouldn’t authenticate as TLS >> clients with certificates. If a backend service needs to take the role of a >> TLS client, a certificate from some PKI is a fine way to solve that. But >> there is no reason for that to use the same PKI hierarchies as web server >> authentication. > > Ok, I'll play along for now. Name a single CA that I can go to right now to > get a certificate with EKU clientAuth issued towards > dNSName=myserver.frank.fyi that your devices would trust without additional > configuration. There is none. Therefore this argument is invalid. > > In addition having clientAuth and serverAuth within the same certificate was > also used as a cheap way to do channel binding. When you've two systems where > either of these systems can initiate a connection like with e.g. IPSec then > having a single certificate with both clientAuth and serverAuth within it > allows to securely mutually authenticate the connection regardless of what > side initiated it. And that is the scenariou in common here. Well now you may > say EKU 1.3.6.1.5.5.7.3.17 exists, however what CA coud I go to to get such a > certificate that you trust without having to install a new Root CA into your > operating systems trust store and therefore also grant the right to issue > e.g. 1.3.6.1.4.1.311.20.2.2, 1.3.6.1.5.2.3.5, or 1.3.6.1.5.5.7.3.1? Right, > none. Hence why commonly almost everything built around of this problem > started to use "serverAuth" 1.3.6.1.5.5.7.3.1 (which in the RFC is refering > to a web server but within the documentation of CAs only referes to "Server > authentication") and "clientAuth" (which the RFC also specified for web > servers but CAs commonly listed them as "Client authentication" > certificates). See e.g. Digicerts documentation: > https://docs.digicert.com/en/trust-lifecycle-manager/inventory/certificate-attributes-and-extensions/extended-key-usage.html > > Splitting that into two certs not only often isn't supported without a > software change (that on some platforms will at the soonest land in 2027) but > also would break that kind of channel binding and require a protocol change > to rework the authentication as now the TLS-server can't be sure it is > talking to the same system for a specific inbound connection as it would for > an outbound connection. To be fair that drawback is minimal, but so is having > clientAuth and serverAuth within the same certificate for a web browser... > >> You could use entirely private hierarchies, hierarchies >> shared across a large class of applications (e.g. all of S/MIME), or >> anything in between. > > One of the reasons for why mutual TLS between all of the MTAs failed was the > lack of a common trust store. Others worked around this by using the > operating systems certificate store, aka Web-PKI (+ maybe 1 or 2 irrelevant > additions). > > I give you the point that people probably shouldn't have integrated the > Web-PKI in operating systems that deeply and allow it to be used for any and > all CA validation without restrictions. And I would also give you the point > that it was kinda lazy for people having this use case to not go through the > trouble of setting up an entire PKI infrastructure and getting it into all > operating systems in existance to get the same kind of "is universally > trusted" as the Web-PKI. However the Web-PKI allowed for this usecase and > this policy change cuts off all of these without enough time to deal with it. > > Heck I probalby would even give you the point that relying upon Google was a > bad idea from the start and pushing something decentralized that isn't > controlled by a single entity like DANE would have been a better design, but > here we are... > >> As noted elsewhere in this thread, and in the >> references you linked, this is the standard way you build applications with >> TLS and X.509: >> https://github.com/cabforum/servercert/issues/599#issuecomment-2954343849 >> https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427/70 >> https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427/92 >> >> Separate hierarchies allow the policies around each to be tailored to the >> needs of specific relying parties that support them. In the case of client >> and server certificates, they’re already entirely separate roles in the >> protocol, so there is no benefit in tying them together. > > Again, you're right in theory. However (and this is the common theme of all > discussions to this topic) it doesn't change the reality that it was used > differently. The CA/B Forum for example INTENTIONALLY after long discussions > put a "MAY" into their policy for exactly this reason. Your policy makes this > a very clear "fuck you freeloaders, we dictate it's now a 'MUST NOT'. Eat > shit and die". Yea, shot taken, we kinda were freeloaders. However you know > that we exist, we used it that way for decades (even way before Let's Encrypt > existed), it was so universally used in different areas that it is just way > too "not considerate" from your part. Don't get me wrong, I don't mean you > doing this change. The HOW is what is the main issue here. > > Literally any of these would have made it less painful: > * Not demanding the entire tree to be only CAs and "serverAuth"-leafe > certificates. Aka allowing a CA to have a sub-CA within the same tree that > issues clientAuth certificates towards devices. > * Ensuring that at least one similarly wide spread trusted CA outside of the > Web-PKI tree issuing domain validated clientAuth certificates exists before > pushing such a policy change. > * Setting a deadline after e.g. 2028 to allow for changes to be put into each > and every stable distro before it hits. And writing into the policy that CAs > have to actively inform their customers about this upcomming change with each > and every renual upon that date. Changes like e.g. DANE support or do the > (almost) impossible of getting all kinds of different projects that never > before used to talk to each other but were implemented a common protocol to > come together and spinn up their own PKI tree. > * Making the final deadline 2028 and for now just stop including clientAuth > by default BUT allow CAs to do it upon an explicit request. > * ... > > My draft is just another way to do this transition. In my eyes did you with > this policy change start the end of the PKI tree. I think within my draft I > also made it already quite clear that DANE without a pre-populated trust > store is the future. Either specify the issuing ca using type 2 or pin the > self-signed certificate using type 3 directly. > >> This goes in both directions. The Web PKI allows a service that speaks HTTP >> on port 80 to obtain a certificate. (This is the ACME http-01 challenge.) > > Or using DNS-01 using a TXT-RR, TLS-ALPN-01 using port 443, ... > > It never was "just HTTP on port 80". Many of these mutual TLS use cases > either used to run a certbot on port 80/443 exclusively to get these > certificates or used the DNS-01 challange. > >> That makes sense for web servers. It might not make sense for arbitrary >> backend-to-backend applications, where port 80 may be served by a less >> trusted process. Web serving and backend-to-backend communication are >> different applications, with different needs. > Then one could still use one of the other challange types. OR buy a > certificate from a CA that didn't use ACME for the validation to begin with. >> Hope that helps give some background on how TLS uses certificates! > > Hope my comments give you some background on how we used to use TLS in the > field for literally decades. > > This condescending attitude is also a common theme it doesn't make discussing > the issues any easier. It also is quite hard to keep things professional when > being faced with this kind of attitude in combination with any and all > arguments being discarded. Frankly speaking it appears I'm also not the only > one feeling this way as I've seen already a bunch of people writing > conspiracy posts stating this being a desperate move by Google to kneecap the > competition of decentralized and p2p alternatives and try to stay one of the > dominant forces in the internet. Especially considering that it was exactly > timed right as currently a lot of people are considering their options to > reduce US-dependencies here in Europe. Like moving from YouTube to PeerTube > or from Twitter to Mastodon and there like. > >> David >> >> On Tue, Jun 17, 2025 at 9:17 AM Klaus Frank >> <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org> >> wrote: >> >>> >>> Hi, >>> >>> because of recent events with policies of public CAs and associated >>> "fallout" that removed the ability to get publicly trusted certificates >>> with clientAuth for dNSName and ipAddress I've written this early draft of >>> a now standard I'd like to propose. As this breaks any and all mutual TLS >>> authentication between systems relying upon public trusted certificates >>> (like XMPP, AD FS, or SMTP with mutual authentication, like e.g. the >>> Microsoft Exchange Hybrid deployment uses) some solution is required. >>> >>> Within this draft I basically sharpen the definition of "id-pk-clientAuth" >>> and "id-pk-serverAuth". "id-pk-clientAuth" should no longer be used for >>> dNSName and ipAddress (aka device) certificates and instead a TLS-server >>> should be allowed to accept a "id-pk-serverAuth" certificate. As long as it >>> expects device-to-device authenticated sessions. This should also address >>> the obscure and unspecified "security concerns" the Google Chrome team >>> stated as reason for the policy change that caused any and all CAs to drop >>> issuing clientAuth certificates. Even the ones that still issue >>> certificates with the clientAuth flag set do NOT do so for devices and only >>> for endusers and organizations (EV and OV). >>> >>> Besides that as also Lets Encrypt stopped including the clientAuth flag >>> the only free and publicly trusted certificates available are of type >>> id-pk-serverAuth". Therefore to keep systems relying upon the mutual >>> authentication of TLS between servers operational it is necessary to allow >>> servers to use id-pk-serverAuth certificates for TLS-Client Authentication. >>> In addition I also tried to outline how a server should validate the >>> received TLS certificates. >>> >>> The validation of the client certificate may currently be a bit too >>> verbose and complex. The main goal is to do forward-confirmed reverse DNS >>> lookup, allow for DANE/TLSA provided certificates, as well as services >>> behind SVCB and SRV records (this part may be unnecessary and maybe can be >>> scratched from the draft, I'm not entirely sure). I also provided steps for >>> verifying the source port which may also be unnecessary. >>> >>> I would have hoped that we've more time on this matter, but as the first >>> CAs already stopped issuing such certificate and the commonly used lets >>> Encrypt certificates are not valid that long either this topic is kinda >>> urgend. I'm open to alternative solutions though. It would be great to find >>> some people to push this forward to at least have a standard to move over >>> to. Instead of being left with a bunch of broken services. >>> >>> Sincerely, >>> Klaus Frank >>> >>> >>> Further links for the background of the above referenced policy change: >>> * https://googlechrome.github.io/chromerootprogram/ >>> * >>> https://community.letsencrypt.org/t/do-not-remove-tls-client-auth-eku/237427 >>> * https://github.com/processone/ejabberd/issues/4392 >>> * https://github.com/cabforum/servercert/issues/599 >>> >>> >>> A new version of Internet-Draft >>> draft-frank-mtls-via-serverauth-extension-00.txt has been successfully >>> submitted by Klaus Frank and posted to the >>> IETF repository. >>> >>> Name: draft-frank-mtls-via-serverauth-extension >>> Revision: 00 >>> Title: Allow using serverAuth certificates for mutual TLS (mTLS) >>> authentication in server-to-server usages. >>> Date: 2025-06-16 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> https://www.ietf.org/archive/id/draft-frank-mtls-via-serverauth-extension-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-frank-mtls-via-serverauth-extension/ >>> HTML: >>> https://www.ietf.org/archive/id/draft-frank-mtls-via-serverauth-extension-00.html >>> HTMLized: >>> https://datatracker.ietf.org/doc/html/draft-frank-mtls-via-serverauth-extension >>> >>> >>> Abstract: >>> >>> This document aims to standardize the validation of mutual TLS >>> authentication between servers (server-to-server). It outlines >>> recommended validation flows as well as provides practical design >>> recommendations. Basically the EKU id-kp-clientAuth and id-kp- >>> serverAuth get more precisely defined to represent their common >>> understanding by issuing CAs and browsers. id-kp-clientAuth aka. >>> "TLS WWW client authentication" SHOULD mean authentication of a >>> natural or legal entity. id-kp-serverAuth aka. "TLS WWW server >>> authetnication" SHOULD mean authentication of a device. When two id- >>> kp-clientAuth certificates are used this means E2E authentication >>> between two users. Where as two id-kp-serverAuth certificates being >>> used means server-to-server authentication. And one user and one >>> server certificate within one TLS connection means client-to-server >>> (or technically also server-to-client). The term "TLS-Client" SHOULD >>> no longer be used and mean the party sending the initial package >>> while establishing a TLS connection. This helps to avoid design >>> issues moving forward as currently some people thought TLS-Client >>> auth was only ever used in "client-to-server" and never within >>> "server-to-server" context. Which sparked the demand for this >>> document to begin with to keep server-to-server auth with public >>> trusted certificates working. >>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org >>> > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
