IMHO, no reason to add post_handshake_auth to TLS 1.2, because TLS 1.2 already supports renegotiation. While renegotiation had its share of issues we had to patch over time, doing TLS 1.2 client auth without renegotiation leaks client identity.
Cheers, Andrei From: TLS <tls-boun...@ietf.org> On Behalf Of Rob Sayre Sent: Friday, March 31, 2023 8:20 AM To: David Benjamin <david...@chromium.org> Cc: TLS@ietf.org Subject: [EXTERNAL] Re: [TLS] TLS 1.2 deprecation On Thu, Mar 30, 2023 at 3:58 PM David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> wrote: post_handshake_auth was only in TLS 1.3 because some folks relied on an existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a renegotiation and request a client certificate in the new handshake. I don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such a backport would also require much more analysis than the average extension, since it concerns authentication. No disagreement from me. My point was only that such things are already in the IANA registry. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
