Be more explicit about PSK requirements #1061
Conversation
Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment. Closes: tlswg#1040 Closes: tlswg#1043
draft-ietf-tls-tls13.md
Outdated
| - The selected ALPN {{RFC7301}} protocol, if any. | ||
| - The selected SNI (Section 3 of {{RFC6066}}) value, if any. |
There was a problem hiding this comment.
list construction: remove the period
There was a problem hiding this comment.
I would move the text on external vs. ticket after the list so that you can use a colon. e.g.,
In addition, it MUST verify that
the following values are consistent with those associated with the selected
PSK:
- ...
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.
draft-ietf-tls-tls13.md
Outdated
| match the values negotiated in the connection during which the ticket | ||
| was established: | ||
|
|
||
|
|
|
@ekr ping? It would be good to get some resolution in this space, as it's somewhat relevant to openssl/openssl#3926 |
|
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are. |
|
@ekr is there a path forward for this (e.g., does it need to go to the list)? |
SGTM. Do you need me to adjust the patch? |
|
Nah, I'll do it. |
|
These actually just seem to make the SNI requirements clearer but no sharper, so merging. |
In order for cross-SNI resumption to work, SNI has to be a per-connection property. Reflect this in text.
Both for 0-RTT and 1-RTT.
Give NST- and externally-provisioned PSKs more uniform treatment.
Closes: #1040
Closes: #1043