[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066

[Filippo Valsorda <[e-mail]>]

Getting roots to ship with operating systems is certainly a hard multi-year project, but why does ejabberd or an MTA need to use the OS root store?

If the XMPP and/or SMTP ecosystems feel the need for a PKI which behaves differently from the WebPKI, can't they ship the roots of such a PKI with their code?

Boulder is open source and ACME is an extensible protocol, so the barrier to standing up a PKI has never been lower.

2025-06-19 00:46 GMT+02:00 Klaus Frank <draft-frank-mtls-via-serverauth-extension=[e-mail]>:
> 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=[e-mail]>
> > 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 -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >>
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>