Re: [TLS] Connection ID Draft

[Matt Caswell <[e-mail]>]

On 13 October 2017 at 07:31, Fossati, Thomas (Nokia - GB/Cambridge,
UK) <[e-mail]> wrote:
> To solve this, we'd need a place in the wire image of the record with
> semantics: "I'm carrying a CID."
>
> In 1.2, we could use CT or version.  (In 1.3, that would not be possible
> because the diet header doesn't have them - too bad.)  To me it'd make
> slightly more sense to use the version. (I had previous discussions on this
> topic with Nikos and he told me that though anyconnect does this version
> override for some reasons, there is no reported conflict with middle-boxes.)
> Also, there would be only one code-point to allocate, instead of separate
> code-points for each CID-enabled content type variant.  I'm happy to be
> convinced of the opposite, though.

Recently I met with Yin Xinxing and we have had much the same
conversation about what a Connection ID draft would need to do, and
how we could detect its use on the wire. Mechanisms we talked about
included setting something in the "length" field, using ContentType or
using version. IMO using "length" is just horrible. I'm also not keen
on version - it further complicates the "is this version greater than,
equal to, or less than this other version" question. It's already
slightly complicated in code that implements both TLS and DTLS due to
DTLS versions being high and decrementing for a new version. I foresee
lots of subtle bugs and problems from reusing "version". In my mind
ContentType is the way to go.


> I guess my main point here is to make sure we do as much as we can to allow
> simple, efficient, robust implementations, which are also, en passant,
> Wireshark-friendly, and leave heuristics-based approaches only for when
> there is no real alternative.

I fully agree here! It does occur to me that we could go further along
that road by swapping the order of the "length" and "cid" fields in
the new record header format, so that the new fields appear at the
end. Middlebox/wireshark code would then still be able to interpret it
because the beginning of the header is identical. The length would be
wrong of course (too short by cid_length bytes), but it would still be
parseable. That could be fixed (by adding the cid_length to the
payload length) but I'm not sure if its worth it.

Matt