Re: [TLS] Connection ID Draft

[Christian Huitema <[e-mail]>]

On 10/13/2017 7:29 AM, Eric Rescorla wrote:
>
>
> On Fri, Oct 13, 2017 at 7:16 AM, Stephen Farrell
> <[e-mail] <mailto:[e-mail]>> 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