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

[Eric Rescorla <[e-mail]>]

On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett <[e-mail]>
> > wrote:
> > >
> > > This last bit stops this, yes. I would prefer the spec say this very
> > > explicitly, as right now it doesn't and all I see is a line saying:
> > > "If any of these checks fail, the server MUST NOT respond with the
> > > extension and must discard all the remaining first flight data (thus
> > > falling back to 1-RTT)."
> >
> > Well, this is a general requirement any time the record MAC is bad:
> > See http://tlswg.github.io/tls13-spec/#rfc.section.5.2.2
> > "If the decryption fails, a fatal “bad_record_mac” alert MUST be
> generated."
> >
> > > 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.
>
> Except that when server is doing 1RTT fallback and skipping 0-RTT data,
> then records that get deprotect failure (is that the proper term?) are
> ignored instead of generating bad_record_mac like "normal" deprotect
> failure would.
>
> Then there's also the case where server is skipping 0-RTT data for retry
> (there one can recognize end of data from content-type 23 changing back
> to 22).
>

Correct. These need to be special cased. And of course with DTLS you
just drop such packets rather than terminating the connectin.

However, it's worth nothing that even if the first-flight handshake data
weren't encrypted, it would still not be possible to create confusion
here because the server would still be waiting for the 0-RTT Finished
message prior to being willing to accept application data from the
client.




Then one has to ensure that configuration_id's are never reused: If
> client and server disagree about server-valid configuration, the result
> can easily be hard failure (instead of fallback).
>

Yes, agreed. I had always assumed that configuration ids were unique.


One server-side trick to ensure non-reuse would be to hash the server
> certificate and the configuration messages (with configuration_id being
> zeroes of approriate length) using e.g. SHA-256 and then use the resulting
> hash as configuration_id.
>


-Ekr


>
>
>
>
> -Ilari
>