Subject: [TLS] Upgrading TLS session resumption from TLS 1.2 to TLS 1.3?

From: "Soni L." <[email-masked]>
Date: Thu, 24 Jun 2021 09:36:36 -0300

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?

---

From: David Benjamin <[email-masked]>
Date: Thu, 24 Jun 2021 11:11:31 -0400

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. <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Soni L." <[email-masked]>
Date: Thu, 24 Jun 2021 12:20:52 -0300

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.
>
> 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. <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>