On Thu, Oct 12, 2017 at 11:21 PM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> On Thu, 2017-10-12 at 16:13 -0700, Eric Rescorla wrote: > > Hi folks, > > > > I have just posted a first cut at a connection ID draft. > > https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00 > > I believe the major issue with that is the fact that the record packet > format changes, but there is no way for a party in between to be able > to determine the record packet format without keeping session state. > Think not only of middle boxes, but of super-servers which may receive > of a stray udp packet which they have to forward to the appropriate > server [0]. With that change, they cannot figure whether the packet > contains the CID or not in a deterministic way for a random CID. > > One can hack around that limitation by providing a CID which starts > with 0xffff which is an illegal size currently for TLS or DTLS, but > would have to worry with future extensions to the protocol which may > increase the maximum size. Yes, Thomas raised this issue as well. Unfortunately, we need to take the structure of existing TLS records as it is, and at least in DTLS 1.3 we're going to effort to shorten the header and I'm not eager to make everyone pay on the wire whether they want to use connection ids or not. In DTLS 1.2, as you say, it seems most straightforward to just provide what would be an illegal length, as it seems pretty unlikely that any future DTLS extension is going to allow 65k-sized packets. In DTLS 1.3, we could probably steal one code point for this if we had to. Another worrying feature is that the client can make the server send up > to 255 verbatim bytes on the wire of his choice. Why was this feature > added? Are there use cases related with it (intro doesn't mention any), > or it was only thought as a make it as generic as possible approach? If > it is the latter, I'd recommend to provide a simple approach that > covers the described use cases. > Well, any connection ID feature of this type involves forcing the other side to send a certain amount of fixed verbatim data, so we're really just debating how long that value ought to be. There are good reasons to allow at least 16 octets (in the super-server case you suggest, you might want the connection ID to to be an encrypted label for the actual server, and it's much more convenient to encrypt 16-byte quantities because that's AES's block size and many of those machines will have AES-NI). And once you're carrying 16 bytes, I don't see a big point in minimizing it below that. If people want an upper limit that is greater than 16 (32?) I would be fine with that. -Ekr The same argument applies to the server being able to set such a long > sequence of verbatim bytes to each of the client packets. > > regards, > Nikos > > [0]. That was exactly my use case for introducing the CID info, as in > openconnect server, the super-server receives the stray UDP packets > arriving after a NAT disassociates existing connections. > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
