On Fri, Mar 17, 2017 at 4:32 AM, Matt Caswell <fr...@baggins.org> wrote:
> On 17 March 2017 at 00:03, Martin Thomson <martin.thom...@gmail.com> > wrote: > > On 17 March 2017 at 10:58, Matt Caswell <fr...@baggins.org> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
