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