Re: [TLS] Connection ID Draft

[Nikos Mavrogiannopoulos <[e-mail]>]

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.