Re: [TLS] DTLS 1.3

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 04, 2016 at 01:56:01PM -0700, Eric Rescorla wrote:
> On Mon, Jul 4, 2016 at 1:46 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> > I think the obvious way is:
> >
> > - Cookies from HelloVerifyRequest go to legacy cookie field.
> > - Cookies from HelloRetryRequest go to extension cookie field.
> >
> > If you don't do the first, you can't downnegotiate successfully. And
> > if you don't do the second, you would have to have special case with
> > cookie sizes (since HRR can transmit >255 byte cookie, which would be
> > too big for legacy cookie).
> >
> 
> IMO we should just forbid HVR for DTLS 1.3. I.e., you should just send
> HRR.

Yes, DTLS 1.3 servers can't send HVR, but that doesn't mean DTLS 1.3
clients can't receive HVR (and then need to handle it somehow).

And if downnegotiation is to be possible, then that way should be
compatible with DTLS 1.2 (sticking the cookie into legacy cookie
field and clearing the hash should be compatbile enough).

> > > - The handshake retransmit scheme doesn't seem to work that
> > > >   well with post-handshake auth, and even less well with
> > > >   session tickets.
> > > Why do you think so? Of course, unreliable transports creates
> > > inconvenience; is it that what you are referring to?
> >
> > DTLS assumes handshake messages are reliable, and that reliability is
> > implemented via handshake messages ACKing one another.
> >
> > - Session tickets have no ACK at all.
> >
> 
> DTLS 1.3 should add an ACK, IMO.
 
Yeah, not going to work without. And I presume something might be
needed for dynamic reauth too...
 
> > - CertificateRequest can have very slow ACK.
> > - KeyUpdate has no real ACK (and isn't idempotent either).
> >
> 
> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch
> instead.

How many special epochs we need?

0 => Unencrypted messages
1 => 0-RTT control messages (just one finished[1]!)
2 => 0-RTT data messages
3 => primary handshake
4 => application data
5-N => rekey connection

Would that be enough?

Reserving epochs would clearly expose the 0-RTT records and the
handshake through. Would solve the reordering with 0-RTT tho.


And can epochs wrap around (this would not cause problems with nonce
reuse, since keys are not going to match)?



[1] Whereas in TLS 1.3 that finished seems pointless (you have a
MAC to check anyway), now in DTLS if there are no 0-RTT handshake
messages, there is no guarantee that any 0-RTT message is received,
resulting no MAC to check.



-Ilari