Thanks for the feedback Ben and David.
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.
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:
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
