Re: [TLS] Updated DTLS draft

[Matt Caswell <[e-mail]>]

On 17 March 2017 at 00:03, Martin Thomson <[e-mail]> wrote:
> On 17 March 2017 at 10:58, Matt Caswell <[e-mail]> wrote:
>> In DTLS1.3 the cookie is now (potentially) much larger and appears much later in
>> the ClientHello, making it much more likely that it will not fall
>> fully within the
>> first fragment. This could mean a fully stateless solution is impossible.
>
>
> I think that it is feasible to simply require that ClientHello be
> contained in a single datagram.

Yes, this is one of several solutions - although it is possibly a
retrograde step. With the assumptions that I currently have for
DTLSv1.2, even with max size cookie and session id the full cookie
will always be contained within the first 346 bytes of the record (if
I did my sums right) - which doesn't seem unreasonable. So as long as
the first fragment isn't smaller than that then, with our current
implementation, we are good.

By stating that the *whole* ClientHello must be within the first
fragment we are placing some significant restrictions on the
extensibility of the protocol and how much we can stuff into it.
Fragmenting the initial ClientHello does happen even in DTLS1.2
(before we've added extra ciphersuites and extensions for DTLSv1.3) -
we had a recent report of someone having problems when receiving
fragmented ClientHellos:

https://mta.openssl.org/pipermail/openssl-users/2017-February/005332.html

Another option is to say that the cookie extension must be fully
contained within the first fragment - which avoids the above
extensibility concerns. This option is much better but is still
retrograde from DTLS1.2 because the extensions block appears later in
the ClientHello (most importantly after ciphersuites, which could be
quite long).

A third option is to retain use of the cookie field in DTLSv1.3 and
require that the first fragment contains it, i.e. the server sends the
cookie in the HRR and the client reflects it back in the cookie field.
This would solve all of the above problems but introduces a new one -
the TLSv1.3 max cookie length is bigger than the length of the cookie
field. There are a couple of ways around that that I can think of -
the simplest being that DTLS1.3 could restrict the max cookie length -
but that in itself could cause some problems due to the fact that more
data needs to be stored in the cookie for DTLS1.3 (i.e. the transcript
hash).

>  QUIC does this and when we did the
> sums it wasn't completely unreasonable, even assuming several key
> shares and a big-ish cookie.  And then we made it possible to make the
> cookie even smaller in -19.

Did we? How did we do that?

Matt