It seems that draft-mattsson-tls-psk-ke-dont-dont-dont also deprecates
some other stuff. However, it does not seem to deprecate session_ticket
(recommended=Y!).
That extension is flawed in multiple ways, and those flaws interact in
nasty ways, with end result worse than psk_ke. If psk_ke warrants
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/tl
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 bac
On Thu, Mar 30, 2023 at 3:58 PM David Benjamin
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 ma
Just a thought, but in the discussion of TLS 1.2, we might start to consider
the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated
sooner. RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so
maybe requiring it (or not supporting TLS 1.2 if that cannot
FWIW, my plan for the draft (which I hope to submit for adoption within a
month) is to include text that says, basically, while no new features will be
ADDED to TLS 1.2, the WG may decide to deprecate or remove things that have
become security risks. I think it's better to keep specifics in sep
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 On Behalf Of Rob Sayre
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
