Re: [TLS] Connection ID Draft

["Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[e-mail]>]

Hi Martin,

sorry for taking so long to replay.

> On 18/10/2017, 09:08, "Martin Thomson" <[e-mail]>
> wrote:
> 
> On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <[e-mail]> wrote:
> > This is quite similar to the trial and error / heuristic that I was
> > mentioning in [1].
> 
> You didn't mention 5-tuples.  And it isn't trial and error: you use
> 5-tuple as your primary key and use connection ID to latch.

We seem to have a slightly different opinion on the meaning of trial and
error :-)  But more importantly, we seem to disagree on whether parsing
a binary header is orthogonal to context lookup (either via 5-tuple or
CID) or not.

> > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails
> > to recognise A.1 as CID-enabled and sends it forward to the crypto
> > handler when it shouldn't.
> 
> As I said before, any connection without a connection ID monopolizes
> that 5-tuple making it inaccessible to other connections.  I think
> that in this case: too bad.

I'm not sure I agree with that.  CID should be the tie breaker exactly
in these situations.  When something like that happens, if your
implementation supports CID it should win/survive over one that doesn't.

> > And the already discussed limitations:i
> > - Fragility on corner cases (e.g., the 5-tuple swap above);
> 
> I don't see how you can avoid this in the general case.  Any
> connection without connection ID is going to be hard to correlate if
> it moves.  As for the connection that does have a connection ID but
> moves on top of a connection that doesn't, I don't think that is an
> acceptable loss.

I think you mean "I do think that is an acceptable loss", or "I don't
think that is an unacceptable loss", right?
 
> > - Forcing middleware to keep state;
> > - Breaking wireshark & co unless they can see the whole session;
> 
> Both of these are acceptable to me.  Unless you can describe a
> middlebox use case that needs access to this information and can't
> deal with the solution that I described.  Wireshark and co will need
> to see the handshake if they want to decrypt and that's the only case
> that is important.

For diagnostics, it'd be pretty useful if one could filter a capture by
CID and follow *that* session among lots of others.  Irrespective of
what's in the encrypted payloads (which one can probably get from the
endpoint, if needed).  This is one use case that seems very useful to me
and doesn't require wireshark to keep state.  I'm not saying that there
are no work-arounds: we know how to make do with pcap filters.  But I'd
prefer to design something that is simple and cheap to implement and use
in the first place, if possible.

What I'm asking for is a codepoint and an explicit length for the CID,
i.e., a total +1 byte per 1.2 record on the wire.  I'm not sure the
tiny saving we get with the current proposal justifies the increase in
complexity.

> > - (Depending on the use case, the cost of the two lookups per record
> >   on the parsing might have a performance impact.)
> 
> The second lookup only happens after a migration.

In the IoT use cases, re-binding during a sleep cycle is the common
pattern, so the second lookup is going to be fairly common.

> I neglected to mention that successful use of a connection ID causes
> the 5-tuple to be assigned to that connection; there's a trick there
> in that you need to watch for reordering, but it saves the double
> lookup.

The thing that makes me slightly nervous is that we are talking about
doing trial & errors (at least in my definition of the term) and other
implementation tricks to achieve the very trivial task of parsing a
binary header.  This is what makes red flags pop up and makes me
think that we can do better.

Cheers