Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?

[Ilari Liusvaara <[e-mail]>]

On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <[e-mail]>
> wrote:
> 
> > For DTLS, we have to consider the packet injection threat. It is fairly
> > easy to send some random bytes with a fake source to a UDP destination.
> > Such attacks should not cause the DTLS association to fail! The normal
> > behavior ought to be to just ignore UDP packets that fail to decrypt. This
> > would cause 0-RTT rejects to just result in dropped packets. Can we ensure
> > that the handshake protocol is robust against that?
> >
> 
> We obviously need to distinguish here between handshake and application
> data messages, because DTLS is intended to allow loss of application data
> messages.
> 
> WRT handshake messages, as I indicated before, I believe that there is
> enough information in the handshake messages to prevent removal.
> Namely:
> 
> 1. The ClientHello contains an indication that 0-RTT handshake messages
> are coming.
> 2. The Client's 0-RTT Finished contains a MAC of all the Client's
> 0-RTT messages.
> 3. The Server's Finished contains a MAC of the ClientHello.
> 
> Thus, provided that the client and server in fact share a configuration
> (which, again, is in the ClientHello) then the server knows at the time
> of receiving the first-flight Finished that he has (or has not) received
> all the client's 0-RTT Handshake messages. [0].

Also, maybe a stupid question:

While the 0-RTT handshake parts are obviously reliably transmitted, is
the same true for the 0-RTT data part?

That is, is the server allowed to ACK the flight after having received
ClientHello/Certificate/CertificateVerify/Finished; and deal with any
0-RTT data messages should they arrive (these are not necressarily
retransmitted if lost)?

Or if the context does not support early auth, just ACK immediately
after ClientHello.

It occurs to me that data messages in DTLS 1.2 lack the fields needed
for automatic retransmission.

> The more interesting question, however, is what drives the DTLS state
> machine forward to ensure progress in the face of innocuous loss.
> The basic DTLS design is that the receipt of the first message of the
> peer's next flight indicates receipt of the entire flight. In this case,
> then, the receipt of the ServerHello would indicate receipt of the
> Client's 0-RTT Finished. However, this would place a requirement
> that the server not *send* the ServerHello until that point, which we've
> left open in WIP-11 by not hashing in the 0-RTT plaintext.

I think that would be fairly easy way to deal with it (not saying that
simpler ways don't exist).



Also, on topic of DTLS 1.3... It occurs to me that naively doing it
would leave it open to "fragementation attacks" a'la IPv6.

Basically, it occurs to me that ClientHello messages SHOULD NOT be
fragmented (at TLS level, SCTP(?) or IP level fragmentation is another
kettle of fish) and if it is fragmented, the Cookie extension MUST be
in the first fragment.

The 0-RTT messages aren't so bad as those can just be dropped if
server does not want to accept right now.

Also, there's question of how to handle HelloVerifyReqest (one can't
just downgrade to DTLS 1.2!). One way:

- If it was in reply to ClientHello with EarlyData extension (at least
  with early auth?), treat it as fatal protocol_version Alert. TLS 1.2
  can't handle early data.
- If it was in reply to ClientHello without EarlyData extension, write
  the cookie into the header cookie field (not extension cookie field)
  and resend. This counts as a retry.



-Ilari