Re: [TLS] TLS1.3 Ticket Usage Across Versions

[Benjamin Kaduk <[e-mail]>]

On Fri, Nov 12, 2021 at 04:23:12PM -0800, Steven Collison wrote:
> Hello,
> 
> While testing a TLS1.3 client implementation, I found an unexpected
> behavior. Specific sequence:
> 1. Client negotiates TLS1.3 with Server.
> 2. Server sends NST with a valid ticket.
> 3. Client reconnects to the same Server. The ClientHello contains both the
> `session_ticket` and `pre_shared_key` extensions. The value of the
> `psk_identity` is equal to the value of the `session_ticket`.
> 
> Is it ever valid for a client to populate both extensions with the same
> ticket value? Even if the client reconnects and lands on a different server
> node that only supports TLS1.2, resumption should fail because the protocol
> version should be included as part of the session state. The
> `session_ticket`  extension data in this example is at least wasted data.
> 
> I did not see anything in the spec(neither 8446 2.2 nor 4.6.1) that
> explicitly disallows this. 2.2 contains “Both mechanisms are obsoleted in
> TLS 1.3.” when referring to `session_ticket` and `session_id` resumption,
> but that may not be clear enough.

"Obsoleted in TLS 1.3" is not a very good argument, since we do allow
sending a ClientHello that will be valid for both TLS 1.2 and TLS 1.3.

I think the relevant requirement here (phrased as binding on the server,
but by extension on what the client should expect) is in
https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.1:

   Any ticket MUST only be resumed with a cipher suite that has the same
   KDF hash algorithm as that used to establish the original connection.

There is some history to that part of the text that used to have a longer
list of requirements (e.g., including matching SNI), but it got trimmed
down over time to just this one, needed for safety of the key schedule.

There is a certain reading that treats "KDF hash algorithm" as including the
KDF construction itself, i.e., limiting the protocol version used, though
there can be cases where the TLS 1.2 PRF uses the same hash algorithm used
for a TLS 1.3 HKDF, so it's not an ironclad argument.

Contrast this to the requirements for using early data, https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.10:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are the same as those associated with the
   selected PSK:

   -  The TLS version number

   -  The selected cipher suite

   -  The selected ALPN [RFC7301] protocol, if any

For early data, the TLS version is indeed specifically called out.


My recollection of the discussions leading up to
https://github.com/tlswg/tls13-spec/commit/fc685853ce52a320fa99cd46e48cf7f8954ff663
are that the TLS 1.3 session ticket was to be tied to the protocol version, but
the text doesn't really seem to support that.

So, in summary, I don't think it's ever actually valid to populate both, but
I can't find solid evidence in RFC 8446 to support that claim in the amount
of time I allocated to look for it just now.

Thanks for asking; it's interesting to hear about such an unusual client implementation!

-Ben