Re: [TLS] Connection ID Draft

[Eric Rescorla <[e-mail]>]

On Fri, Oct 13, 2017 at 7:52 AM, Stephen Farrell <[e-mail]>
wrote:

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

Well, this is a lot more complicated for the client and unless you place
very strict limits on lb-id, it ends up with the server just dictating an
identifier to the client so you have the scheme in this draft.



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

That's actually a design that people consider quite often and has been
discussed
for QUIC.



> 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:-),


Sure but we contemplated a number of these designs for QUIC, so we're not
starting from scratch here.




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

I'd say three things here:

1. First, as I said we considered a lot of different designs for providing
better unlinkability than the design in this draft, and none of the
ones that did significantly better had reasonable scaling properties.

2. The precise point of designing this as an extension is that if we
had a better design we could drop it in with a new extension code point,
so accepting this design doesn't preclude anything.

3. You seem to be claiming that your design has better linkability
properties than the design in this draft, but as far as I can tell that's
not correct. In both cases, either side can occasionally change
conn-ids (you can't change in each packet for the scaling reasons
I indicated). In your design one side does so unilaterally, but there
are packet loss concerns, and in the draft, you have to solicit new
conn-ids from the peer but as long as you have one you can change
unilaterally.

The primary difference in your design is that the IDs are opaque
rather than containing data contributed by the other side, but that
difference is immediately weakened as soon as you try to introduce
structure to handle things like the server topology and also comes
at the cost of needing a much larger ID space in each packet to
avoid hash collisions.

-Ekr


> Cheers,
> S.
>
>
>
>
>