Ah, okay. That's unfortunate, tho, resumption upgrades would be useful with TLS-SRP, to get the benefits TLS 1.3 brings without having to update login details.
Thanks tho. On 2021-06-24 12:11 p.m., David Benjamin wrote: > No, resumption should happen after version negotiation, and be > declined if inconsistent. The way it works is: > > 1. Suppose the client previously connected to the server and received > a TLS 1.2 session. It connects again. The client supports TLS 1.2 and > 1.3, but doesn't know a priori whether the server now supports TLS 1.3 > server. So, as always, it sends a ClientHello good for either version. > That means, it has TLS 1.3 extensions like supported_versions and > key_shares. It probably also has TLS 1.2 extensions like > ec_point_formats. And it has the TLS 1.2 session identifier, either in > the session_id field or in the session_ticket extension. > > 2. The server negotiates the TLS version before anything else: > > 2a. If the server only supports TLS 1.2, it negotiates that and > resumes the TLS 1.2 session, as usual. This is important because it > allows clients to enable TLS 1.3 without regressing existing TLS 1.2 > servers. (Of course, TLS 1.2 resumption has weaker privacy and > security properties than TLS 1.3 resumption, so the client > /may/ eventually choose to reduce or remove TLS 1.2 resumption, but > that's a separate decision from enabling TLS 1.3.) > > 2b. If the server supports TLS 1.3, it negotiates that. Sessions are > not resumed across versions and TLS 1.3 doesn't even use the same > ClientHello fields for session identifiers, so the server ignores it > and does a full handshake. This new connection will likely issue a new > TLS 1.3 session to the client. That should replace the TLS 1.2 session > in the client's session cache, so the next connection will resume at > TLS 1.3. > > This is generally the pattern with resumption. The client offers > everything it is okay with: the session, older versions, and newer > versions. The server evaluates its preferences and then only resumes > if the session is consistent with them. > > David > > On Thu, Jun 24, 2021 at 8:50 AM Soni L. <fakedme+...@gmail.com > <mailto:fakedme%2b...@gmail.com>> wrote: > > What's the story on backwards compatibility between TLS 1.2 session > resumption and TLS 1.3 session resumption? Appendix D. Backward > Compatibility doesn't seem to say anything about it. It seems like TLS > 1.2 session resumption is gonna keep using TLS 1.2 even if both sides > support TLS 1.3? > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls