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

[Eric Rescorla <[e-mail]>]

On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara <[e-mail]>
wrote:

> 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?
>

No, nor for any DTLS data. The assumption is that this is handled at the
layer above.


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)?
>

I would anticipate that this is the correct behavior and in fact this seems
like the right behavior for TLS as well, since part of the point of 0-RTT
data is to stream it ASAP. Note that there is no explicit ACK, though.


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


Yes, this is currently technicaly possible.

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.
>

Sorry, I'm not sure I am processing this. Can you explain in more detail.


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.


Yes, this seems like the right answer. I.e., You only do HVR in TLS 1.2
and as we have discussed previously, once you have sent a ServerConfig,
you have to continue to be able to do TLS 1.3, even if you forget the
config.

Best,
-Ekr