On 10/13/2017 7:29 AM, Eric Rescorla wrote: > > > On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell > <stephen.farr...@cs.tcd.ie <mailto:stephen.farr...@cs.tcd.ie>> wrote: > > > Hiya, > > On 13/10/17 14:56, Eric Rescorla wrote: > > I've seen a number of designs like these, but in general they > > have quite poor scaling properties. Can you describe the precise > > design you have in mind so that we can analyze it. > > Sure, I can try... > > What I'm suggesting is that we define a way that a TLS > node can change the connection ID to a new value that > is hard to link to the old, as a function that can be > used when the implementation chooses to use it. > ... > To change an id, pick a value foo that depends on the TLS > session, e.g. like an extractor, and that is not visible > to the network. Then set next-id to H(foo||prev-id) or > some similar construct. >
The problem with these encrypted or hashed schemes is the scaling part. When you receive a packet from a yet-uncategorized 5-tuple, you have to find the context. It can be "any of the contexts currently establish", so you end up having to try them all, or maybe 1/2 of them in average. That can be a lot of hashes or encryptions. If the sender can only send some token that the recipient already expects, the demuxing becomes much simpler. I like EKR's design. But it is a scheme that can be implemented, and will work. There are edge cases, like controlling how many connection ID a peer is willing to provide in advance. And it tends to fall in the "sharp knife" category of tools, i.e., you have better understand what you are doing. In particular, you need a strategy for breaking the linkability of sequence numbers, otherwise connection-id changes will not accomplish much. But there may well be other issues, like time correlation, or traffic patterns. By the way, the often considered scenario is "what happens if the NAT rebinds and the client does not know." I think a simple heuristic of changing the connection ID when coming out of long sleeps would help a lot there. NAT bindings don't change much if the traffic is sustained. But if the last packet was many seconds ago, the client would be wise to just rotate the connection ID before sending anything new. The other often considered scenarios are variations of the "mobile network". The NAT rebinds because the mobile router moved to a new connection, but the client does not know. I can't think of a good heuristic there, but it certainly would be helpful if the mobile router somehow informed the clients. That's probably easier to engineer than changing connection ID on every packet. -- Christian Huitema
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
