Re: [TLS] Connection ID Draft

[Stephen Farrell <[e-mail]>]

Hiya,

On 13/10/17 15:29, Eric Rescorla wrote:
> There are a number of cases where this is actually much harder to implement
> than a design where one side dictates the connection ID. For instance,
> consider a design where you have a pool of servers P1, P2, ... P_n with a
> load balancer in front.
> Each server i generates connection IDs of the form i || Random. The load
> balancer then just looks at the first byte and routes to the appropriate
> load balancer [0]. In this design, the LB can be totally stateless, whereas
> in the design you propose, it has to (a) have a back-channel to the server
> to get the initial conn-id (b), do crypto (c) store state for all the live
> connections.

Pre-pending a fixed length (known to both sides) load-balancer
ID would be fine, sure. That'd change the function to something
like:
    next-id = lb-id || H(foo||prev-id)

So long as each load balancer is busy enough that still has the
hard-to-link property I think. The length of the lb-id could be
fixed or part of the negotiation, with zero being a fine length
when there's no lb-id needed.

I think this'd work ok regardless of who controls the initial id
value, so long as we don't need ids to work like tickets (where
the id value would be the ciphertext of some state info).

> 
> In addition, consider what happens when you get a CID you don't recognize.
> It might be nonsense but it might be that there was a cryptic CID change
> (e.g., the client did two changes but you missed a packet). You need to
> decide the number of changes you're willing to tolerate and then the table
> has to be that big times the number of connections (or you need to fill it
> in whenever you get an unknown CID, which the attacker can send you at any
> time).

Yes, schemes like this can be worse when packets go missing
around the time of an id change.

However, I think with this scheme (which isn't even on a napkin
yet, just these mails:-), the sending side would just make the
change when they want, and wouldn't signal that it's changed the
id. So, in some cases (say if receivers store current and next,
and id changes and packet losses are infrequent) a single packet
drop would be just that and the id change wouldn't affect things
at all. In the putative nb-IoT case I mentioned before then it
could be a good bit worse unless the receiver stores a bunch of
future ids. (I agree some work is needed to figure out if there's
an acceptable scheme here, so for now I'm arguing that we not
preclude such schemes when adopting your draft.)

In figuring this out, I'd argue that we ought be comparing ideas
like this against two things: 1) the simplest solution that does
allow linkabillity and 2) the costs of setting up a new TLS
session to avoid linkability. While this or similar schemes will
look bad compared to (1), they will likely look pretty good
compared to (2).

Of course, how one evaluates such comparisons will depend on how
serious a threat one considers linkabillity. I'd argue that many
devices that'll need connections ids will be devices where the
possibility of linkability could be a significant threat and where
new TLS session establishment will be rare, so we therefore ought
provide some good method of avoiding linkability.

Cheers,
S.