First, thanks for the draft.
As discussed off-list, wrt framing / wire format, we probably have an
opportunity to do slightly better than this, at least for 1.2.
The thing is that, since there is no flag in the record that says: "I'm
carrying a CID", a receiver has no explicit way to know whether a record is
coming from a CID-enabled session or a legacy-DTLS.
This ambiguity complicates the decoder because the receiving end now needs to
implement a heuristic like:
- let's first assume at offset +11 we have a CID
- and then lookup the SAs store using this "maybe" CID
- if found, OK (*), go on with the parsing
- if not, fall back to assuming at offset +11 we have the length field
and go on parsing
This is not ideal for a bunch of reasons:
1. For every incoming record, the receiver needs to lookup the CID store
just to parse the record;
2. The implementation is more complicate;
3. Heuristics are intrinsically fragile and are known to deal badly with
corner cases (think the many creative ways the many moving parts can conspire:
5-tuple reshuffling because of NAT rebinding, lost state due to reboot/restart
of one or more nodes, co-existing CID and legacy DTLS);
4. Wireshark & co will choke because they typically don't have enough
context to handle the two different framings;
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.
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.
Cheers, t
(*) assuming CID is entropic enough, which may or may not be the case.
On 13/10/2017, 00:13, "TLS on behalf of Eric Rescorla"
<tls-boun...@ietf.org<mailto:tls-boun...@ietf.org> on behalf of
e...@rtfm.com<mailto:e...@rtfm.com>> 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
Comments welcome.
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
