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 protected]> wrote: > 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 > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
