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

From: "Steven Collison" <[email-masked]>
Date: Fri, 12 Nov 2021 16:23:12 -0800

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.

-Steven

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 12 Nov 2021 17:21:11 -0800

On Fri, Nov 12, 2021 at 04:23:12PM -0800, Steven Collison wrote:
> 3. Client reconnects to the same Server. The ClientHello contains both the
> `session_ticket` and `pre_shared_key` extensions. The value of the
> 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.
> 
> 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

---

From: David Benjamin <[email-masked]>
Date: Mon, 15 Nov 2021 11:44:50 -0500

It could be valid to populate both if the client wishes to offer both a TLS
1.2 session and a (different!) TLS 1.3 session. I don't believe there's any
prohibition on this per se. But I've not heard of any client doing this. It
seems needlessly fussy and interacts awkwardly with the appendix C.4
mechanism. (And sending an empty session_ticket extension along with
pre_shared_key is quite common since empty session_ticket is how one
signals support for TLS 1.2 tickets at all.)

But that's not what's going on here, since the client is apparently
offering the same session in both places. I don't think it'd cause anything
terrible (this isn't one of the two load-bearing version/session
checks), but it is a waste of bytes and not what the client is supposed to
be doing. One could probably argue that it's implicitly against the spec
because we say TLS 1.3 NewSessionTicket tickets go in pre_shared_key, and
that session_ticket values come from TLS 1.2 NewSessionTicket tickets.

On Fri, Nov 12, 2021 at 8:23 PM Benjamin Kaduk <bkaduk=
[email-masked]> wrote:

> the
> server
> Contrast this to the requirements for using early data,
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.10:
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Steven Collison" <[email-masked]>
Date: Tue, 16 Nov 2021 08:16:21 -0800

Thanks for the feedback Ben and David.

> 1.2 session and a (different!) TLS 1.3 session.

Agreed. This works for cases when a client connects to a server endpoint 
that has a mix of TLS1.2 and TLS1.3 servers. The client uses cached 1.2 
session in `session_ticket`, and 1.3 session in `pre_shared_key`.

> it is a waste of bytes and not what the client is supposed to be 
> doing.

I think we are also agree here. I can make a good argument in a ticket 
filed to the implementation’s issue tracker. If this restriction(1.3 
sessions must not be used in `session_ticket`) is not clear in the spec, 
do we think there is an opportunity to add something? section-4.6.1 or 
appendix-D.1 seem good candidates. I understand there may be good 
reasons to not enumerate restrictions on every possible case of 
misbehavior in the spec.

-Steven

On 15 Nov 2021, at 8:44, David Benjamin wrote:

>> There is a certain reading that treats "KDF hash algorithm" as 
>> including
>> the
>> So, in summary, I don't think it's ever actually valid to populate 
>> both,
>> but
>> Thanks for asking; it's interesting to hear about such an unusual 
>> client
>> implementation!
>>
>> -Ben
>>