On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.foss...@nokia.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
