Re: [TLS] Connection ID Draft

[Martin Thomson <[e-mail]>]

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.

> 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.

> And the already discussed limitations:
> - 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.

> - 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.

> - (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.  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.