Hi Klaus, > As you're from Microsoft and therefore directly affected by this. > Someone already tried to aks you about this but it didn't get an official > statement, see e.g... I work primarily on TLS/PKI/crypto and cannot speak to all of Microsoft products and services (it would be very impressive if I could!) Affected teams are aware, working to address this and will issue guidance as soon as possible, through their normal announcement/support channels.
Cheers, Andrei -----Original Message----- From: Klaus Frank <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org> Sent: Wednesday, June 18, 2025 4:12 PM To: Andrei Popov <[email protected]>; [email protected] Cc: [email protected]; Andrei Popov <[email protected]> Subject: Re: [EXTERNAL] [TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066 On 2025-06-17 21:43:26, Andrei Popov wrote: > Without weighing in on the merits of the CA/B forum policy change, I agree > with what David says below: TLS client and server roles are specific and > well-defined, we cannot redefine them just to get around the new certificate > issuance policy. It's not a "CA/B forum" policy change. The CA/B forum still very intentionally says a server certificate "MAY" contain "clientAuth". It was a change by the Chrome Root Program which in the introduction points towards the "CA/B Forum" which caused this confusion. > It is true, however, that maintaining secure private PKI for client > authentication can be complex/costly and existing services may not have the > necessary functionality to issue client certs. Service operators are now > scrambling to discover/enumerate scenarios where they depend on client certs > chaining to public roots. As you're from Microsoft and therefore directly affected by this. Someone already tried to aks you about this but it didn't get an official statement, see e.g. https://learn.microsoft.com/en-us/answers/questions/2237496/mtls-mutual-tls-or-server-to-server-authentication. Therefore I'd like to ask what your plans for dealing with this issue are. What will you change your recommendation to use publicly trusted clientAuth+serverAuth certificates for e.g. AD FS to mitigate the risk of the others organizations CA issuing fraudulent certs for the partner organization? https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd807040(v=ws.10)?redirectedfrom=MSDN#determining-your-ca-strategy From your documentation: > AD FS 2.0 does not require that certificates be issued by a CA. > However, the service communications certificate must be trusted by the > AD FS 2.0 clients. We recommend that you not use self-signed > certificates for these certificate types. > > Important: Use of self-signed, SSL certificates in a production > environment can allow a malicious user in an account partner > organization to take control of federation servers in a resource > partner organization. This security risk exists because self-signed > certificates are root certificates. They must be added to the trusted > root store of another federation server (for example, the resource > federation server), which can leave that server vulnerable to attack. > > After you receive a token-signing certificate and service > communication certificate from a CA, make sure that both certificates > are imported into the personal certificate store of the local > computer. You can import both certificates to the personal store with > the Certificates MMC snap-in. > Or your requirement for mutual SMTP between on-prem Exchange and O365? These currently also needs publicly truted clientAuth certificates to work properly which no CA is issuing anymore. What do you plan to do to avoid all of these systems of your customer to stop working once the current certificates expire? > Cheers, > > Andrei > > From: David Benjamin <[email protected]> > Sent: Tuesday, June 17, 2025 11:16 AM > To: Klaus Frank > <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org> > Cc: [email protected] > Subject: [EXTERNAL] [TLS] Re: I-D Allow using serverAuth certificates > for mutual TLS (mTLS) authentication in server-to-server usages - > updates rfc5280 and rfc6066 > > (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. > > 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%2Fsecurity%2F2021%2F05%2F10%2Fbeware-of-applications-misu > sing-root-stores%2F&data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976 > f0da6b7d4ab4e1b708ddaebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C > 0%7C638858851300836071%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% > 7C0%7C%7C%7C&sdata=HTJGIkI0hS%2BzE5u7xQwZAMmq6AjyIm5Yrh5rCXccR1U%3D&re > served=0 > > 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. You could use entirely private hierarchies, hierarchies > shared across a large class of applications (e.g. all of S/MIME), or anything > in between. 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://gith/ > ub.com%2Fcabforum%2Fservercert%2Fissues%2F599%23issuecomment-295434384 > 9&data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976f0da6b7d4ab4e1b708 > ddaebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63885885130084 > 3094%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > =NGI9BxWBYLXOEjk8DT4s6OKr8huS95UOvSo0zZsE%2BiQ%3D&reserved=0 > https://comm/ > unity.letsencrypt.org%2Ft%2Fdo-not-remove-tls-client-auth-eku%2F237427 > %2F70&data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976f0da6b7d4ab4e1 > b708ddaebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6388588513 > 00849666%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=jjPPQE0qGX2DibpHiCPuyInE9g9wTfmB%2BL6hmsa2htk%3D&reserved=0 > https://comm/ > unity.letsencrypt.org%2Ft%2Fdo-not-remove-tls-client-auth-eku%2F237427 > %2F92&data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976f0da6b7d4ab4e1 > b708ddaebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6388588513 > 00856483%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=UUinffNX5i5N577TcYfkr7rNXKOFTqmTeioWq%2FsW5RU%3D&reserved=0 > > 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. > > 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.) > 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. > > Hope that helps give some background on how TLS uses certificates! > > David > > On Tue, Jun 17, 2025 at 9:17 AM Klaus Frank > <draft-frank-mtls-via-serverauth-extension=40frank....@dmarc.ietf.org<mailto:[email protected]>> > 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://goog/ > lechrome.github.io%2Fchromerootprogram%2F&data=05%7C02%7CAndrei.Popov% > 40microsoft.com%7C0976f0da6b7d4ab4e1b708ddaebd8a11%7C72f988bf86f141af9 > 1ab2d7cd011db47%7C1%7C0%7C638858851300862735%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bIlTAEwh7jiIU6unM%2Fu7xghvGtK > s48lqHkjULc5yyX8%3D&reserved=0 > * > https://comm/ > unity.letsencrypt.org%2Ft%2Fdo-not-remove-tls-client-auth-eku%2F237427 > &data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976f0da6b7d4ab4e1b708d > daebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638858851300869 > 340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC > IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > N0%2F2u99kkgxufSoAxeMeoW9TplAu2QEhQk%2BqUdanUCs%3D&reserved=0 > * > https://gith/ > ub.com%2Fprocessone%2Fejabberd%2Fissues%2F4392&data=05%7C02%7CAndrei.P > opov%40microsoft.com%7C0976f0da6b7d4ab4e1b708ddaebd8a11%7C72f988bf86f1 > 41af91ab2d7cd011db47%7C1%7C0%7C638858851300876175%7CUnknown%7CTWFpbGZs > b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > oiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ivpd6lMckwpqrMNtqq35oo4P > aPdEhFOay6fa6koR%2FnI%3D&reserved=0 > * > https://gith/ > ub.com%2Fcabforum%2Fservercert%2Fissues%2F599&data=05%7C02%7CAndrei.Po > pov%40microsoft.com%7C0976f0da6b7d4ab4e1b708ddaebd8a11%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1%7C0%7C638858851300882582%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TfR8nfBORDwdeF5z%2B1LyLHf > bxM8eISPEEXa8HGrne6w%3D&reserved=0 > > > 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://data/ > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-frank-mtls-via-serverauth-extens > ion&data=05%7C02%7CAndrei.Popov%40microsoft.com%7C0976f0da6b7d4ab4e1b7 > 08ddaebd8a11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638858851300 > 908480%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > ta=DEs3I%2FlcGjzXx%2Bq8KsSYYM4VR7Cp9sElLRdEbC42GJw%3D&reserved=0 > > > 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 -- [email protected]<mailto:[email protected]> To unsubscribe > send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
