Microsoft Windows Server 2022 supports post-handshake as default authentication method with TLS 1.3. It means, before we can use certificate base authentication with IIS and TLS 1.3 protocol, we must change default configuration from post-handshake authentication method to in-handshake authentication method. So, by default it affects all Microsoft customers who want to enable certificate based authentication with TLS 1.3 in IIS, because enabling certificate based authentication with TLS 1.3 leads us to err_connection_reset error. IMHO this (post-handshake authentication method) is not correct default configuration in situation, where common browsers do not support post-handshake authentication (Firefox supports it, but it is disabled by default).
It is good to hear that post-handshake authentication method is optional and not preferred. Thanks, Urmas From: Andrei Popov <[email protected]> Sent: Friday, January 14, 2022 10:24 PM To: Eric Rescorla <[email protected]>; Urmas Vanem <[email protected]> Cc: [email protected] Subject: RE: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication Essentially, TLS 1.3 post-handshake authentication is analogous to client auth via renegotiation available with TLS <= 1.2. An important difference is that TLS 1.3 post-handshake authentication is optional, and major browsers chose not to support it. In practice, this means TLS server deployments and applications that rely on authenticating clients post-handshake have to change if they want to enable TLS 1.3. These changes can include creating separate endpoints for client-authenticating services, and configuring those endpoints to perform client authentication during the handshake. This affects a significant number of Microsoft customers, who have been using client auth support via renegotiation in IIS. The typical scenario is: landing page without client authentication, then renegotiation with client auth if the user navigates to a protected resource on the page. I recommend customers to work directly with browser vendors if they want TLS 1.3 post-handshake auth support. This is not a TLS 1.3 standard's limitation. Cheers, Andrei From: TLS <[email protected]<mailto:[email protected]>> On Behalf Of Eric Rescorla Sent: Friday, January 14, 2022 9:54 AM To: Urmas Vanem <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: [TLS] TLS 1.3 and certificate based authentication TLS 1.3 supports certificate-based client auth in the primary handshake. -Ekr On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem <[email protected]<mailto:[email protected]>> wrote: Hello! TLS 1.3 introduces post-handshake authentication. It relies on client/browser, client/browser must send post_handshake_auth extension to server before it can work. I hope I understood it correctly. But today we know only Firefox from popular browsers support this extension (and not by default). Question: How can I implement certificate based client authentication against web server in TLS 1.3 only environment, if browsers do not support post_handshake_auth extension. I have open discussion with one big software company. Can you please share your opinion/recommendation here regarding to the issue? Thanks in advance, Urmas _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7Cb2bba7ba2abe443a7a9808d9d787029a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637777797645282331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FuoB5juM%2FxEOU7jezPgyRm6tTN0ChjPXAaAamARZoY0%3D&reserved=0>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
