Re: [TLS] Updated DTLS draft

[Eric Rescorla <[e-mail]>]

On Fri, Mar 17, 2017 at 4:32 AM, Matt Caswell <[e-mail]> wrote:

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

By making the hash state you needed to store a hash value rather than a
hash checkpoint.

-Ekr


>
> Matt
>