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.
On Fri, Mar 31, 2023 at 5:27 AM Rob Sayre <say...@gmail.com> wrote: > Hi, > > What I noticed is that something close to "post_handshake_auth" has been > asked for in TLS 1.2. > > If you go look at the registry, which of course some people here know > well, there are a bunch of them that are only defined for TLS 1.3. > > > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > > Some of them would not make sense in a TLS 1.2 handshake, by my reading. > So, the drift is already happening, quite apart from new feature > development. > > thanks, > Rob > > > On Wed, Mar 29, 2023 at 10:05 PM Rob Sayre <say...@gmail.com> wrote: > >> Hi, >> >> I watched the conversation at the end of this conference here: >> https://youtu.be/u_sFyz4F7dc >> >> It was good. The only thing I would add is that I think client >> authentication is already much different in 1.3, and that new extensions >> such as ECH are already not being done for 1.2. >> >> The thing to do if you have a strong opinion is to not serve 1.2 traffic. >> The clients will always have to be accepting for a while. But, if you've >> worked on the internet for any amount of time, you'll quickly figure out >> that not serving 1.2 will save you money, unless you are Google scale. Not >> because it is way slower, but because you can drop old clients. >> >> thanks, >> Rob >> >> >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
