I'm working on RFC9258 support in OpenSSL, and taking the time to try to
understand as much as I can about TLS 1.3 PSKs in general.
One thing that's a bit puzzling is what appears to be a stricter
requirement around the PSK (slot 0) ciphersuite when early
data is being negotiated:
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
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question. For externally established
PSKs, the associated values are those provisioned along with the key.
For PSKs established via a NewSessionTicket message, the associated
values are those negotiated in the connection during which the ticket
was established.
Now the selected (1-RTT) ciphersuite does not actually come into effect
until after early_data has been consumed, and the 0-RTT cipher suite
could just be whatever was baked into the PSK (with just the digest
(KDF) needing to match the 1-RTT choice in order for the PSK to be
acceptable.
With the 0-RTT keys independent of the 1-RTT keys, why must the full
0-RTT cipher suite match the 1-RTT cipher suite that comes into effect
only later? Or am I misinterpreting the requirement?
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
