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

[Sean Turner <[e-mail]>]

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 [e-mail] <mailto:[e-mail]>.

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=[e-mail]> 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=[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]