The ladder diagram describing the 0-RTT exchange is simple enough, as seen in
this extract:
Client Server
ClientHello
+ KeyShare
+ EarlyDataIndication
^ (Certificate*)
0-RTT | (CertificateVerify*)
Data | (Finished)
v (Application Data*)
(end_of_early_data) -------->
The text indicates that client auth and application data messages are protected
by "keys derived from the static secret." But then, hidden in section 7.2 is an
interesting twist -- too different keys are supposed to be derived from the
static secret, one for 0-RTT handshake, another for 0-RTT Application. If I
understand correctly, the Certificate, CertificateVerify and Client Finished
message would be protected with the "0-RTT Handshake" key, and the Application
data and end-of-early data message would be protected with the "0-RTT
Application" key.
I assume that there is a good reason for this extra complexity, even if it
eludes me. But I worry a bit about what that would do when we start working on
DTLS 1.3. UDP messages can arrive out of order. Yes, there is a message number,
but the record layer is not necessarily well positioned to interpret it -- the
certificate and verify message are optional, so when a record layer receives
packet #3 before packet #2, it does not know whether this is a
CertificateVerify message (handshake key) or an application message
(application key).
Yes, there are solutions, yes, it can be managed, but are we sure that this
particular bit of complexity is worth it?
And if it worth it, can we add a description of the key switching logic in
section 6.2.2?
-- Christian Huitema
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
