[TLS] Do we really need two 0-RTT keys?

[Christian Huitema <[e-mail]>]

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