On 13 October 2017 at 07:31, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.foss...@nokia.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
