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

[Christian Huitema <[e-mail]>]

From: Eric Rescorla [mailto:[e-mail]] 
Sent: Monday, December 28, 2015 1:46 AM
To: Christian Huitema <[e-mail]>
Cc: Dave Garrett <[e-mail]>; [e-mail]
Subject: Re: [TLS] What does it mean to not include 0-RTT message in the handshake hash?



On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <[e-mail]> wrote:
On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote:
> On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote:
> > Well, this is a general requirement any time the record MAC is bad:
> > See
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftlswg.gith
> ub.io%2ftls13-
> spec%2f%23rfc.section.5.2.2&data=01%7c01%7chuitema%40microsoft.com%7
> c57c8404a1f2f41a17f8a08d30e8c8243%7c72f988bf86f141af91ab2d7cd011db4
> 7%7c1&sdata=nTdhU1cC6yaYfKvpIG4JR1vhTgs82gFYgVLJbPYskXQ%3d
> > "If the decryption fails, a fatal “bad_record_mac” alert MUST be generated."
> >
> > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <[e-mail]>
> > wrote:
> > > The current text doesn't explicitly say how to handle 0-RTT data that it
> > > thinks it should be able to decrypt but can't. After rereading things a bit
> > > I think you're correct in that the correct course of action the spec
> > > currently expects is to abort, however implementers frequently err on the
> > > side of working partially vs not at all when given any wiggle room. A clear
> > > hard "MUST abort" on failed decrypt of 0RTT data would deal with this and
> > > avoid any other possible misunderstanding. Either do or do not; no try.
> >
> > If you have suggested text, I'd be happy to see a PR.
>
> Ok, I filed PR 393 with a couple sentences to clarify that 0-RTT records aren't
> allowed special treatment and errors on handling MUST NOT result in a 1-RTT
> fall back.

Isn't that a part where TLS and DTLS will differ a lot?

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


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.

-Ekr

[0] Note, however, that the client has to rely on the server to handle this
properly. The reason