Hi. The point here is not to debate "post_handshake_auth" in TLS 1.2. It's to point out that this extension is already in the registry. So, you already have fairly serious parts of the handshake that don't fit in TLS 1.2.
So, what to do now? I think the deprecation path in the meeting makes sense. thanks, Rob On Thu, Mar 30, 2023 at 7:29 PM Andrei Popov <andrei.po...@microsoft.com> wrote: > 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> > 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
