[TLS] TLS 1.3 PSK vs. early data and cipher suite? (A break from the topic du jour)

Viktor Dukhovni <[email protected]>
Newsgroups gmane.ietf.tls
Message-ID <[email protected]>
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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.