On Fri, Dec 18, 2015 at 2:45 PM, Christian Huitema <huit...@microsoft.com>
wrote:
> 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.
>
Yes, that's correct.
> I assume that there is a good reason for this extra complexity, even if it
> eludes me.
The motivation for this was that a number of people working on analysis
complained
that using the same key to encrypt handshake traffic and application
traffic (as
is done in TLS 1.2 with Finished and application messages) made analysis
harder.
I'm not equipped to take a position on this, but that's what I have been
told. We
already do that for the 1-RTT keys and we're doing the same thing here.
> 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).
>
Note: the Certificate message isn't optional in the sense that the server
doesn't
know if it's coming. Whether it's sent is conditioned on the configuration
(in WIP-11)
an on the client's EarlyDataInfication (in WIP-10).
But your general point is right in that you can have loss and reordering.
So, for instance,
say that the client sends messages with seq nums as follows:
ClientHello: 0 (in clear)
Finished: 1 (with Handshake Key)
AppData: 2 (with app key)
Now, 1 and 2 are lost, and the client retransmits:
Finished: 3 (with Handshake Key)
AppData: 4 (with app key)
If #3 is now lost, the server may not know if #4 is handshake or
application data
since (for instance) the client might have fragmented the Finished over two
records.
Now, I think there are several ways to deal with this. First, the server
can just
continue to attempt to process records with the handshake key until the
handshake
is completed, in which case it will drop #4 and then get the retransmit of
the
Finished (#5, presumably). Second, DTLS has an epoch # used to indicate
which
generation key you are using. We should come down on some deterministic use
of
that in which case things will be obvious.
Yes, there are solutions, yes, it can be managed, but are we sure that this
> particular bit of complexity is worth it?
>
Karthik? Others? :)
> And if it worth it, can we add a description of the key switching logic in
> section 6.2.2?
That seems like a good plan...
Ekr
>
-- Christian Huitema
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
