On Fri, Mar 17, 2017 at 11:32:16AM +0000, Matt Caswell 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. > > 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:
AFAIK, that mostly becomes problem only with group 260 (fortunately, I don't think anyone is crazy enough to use that!) with its 1024-byte public key, or various PQ exchanges (and there even relatively compact ones can easily be even larger). But of course, PQ might become rather important in future. Also, 1200 bytes of packet payload should be feasible. That's well within IPv6 minMTU, and also within reach of virtually all IPv4 links. > 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). There's also the supported versions extension which is important. As for long ciphersuite lists, deimplementing some garbage would fix that. > 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). Well, here's one cookie design: - Key tag: 4 bytes - Encryption prelude: 32 bytes - Timestamp: 8 bytes - Peer address: 16 bytes - Cipher: 2 bytes - Group: 2 bytes - Client Hello hash: 48 bytes - Authentication tag: 16 bytes Total: 128 bytes (could be shrunk to 112 by using prelude as tag, at cost of more complex code). -Ilari. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
