Re: [TLS] Connection ID Draft

[Stephen Farrell <[e-mail]>]

(Sorry for the slow response...)

Two things below...

On 13/10/17 16:58, Eric Rescorla wrote:
> 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.

So, if the WG want to allow for such designs, then I think that'd
be better explicitly stated as some level of requirement, e.g. to
say that some aspect of the scheme needs to allow some cids to be
an encrypted form of something else. (I do think allowing for such
is quite reasonable.)

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

I think the design I outlined does differ somewhat from the draft.
In the draft the new connection ID has to be sent explicitly, but
in this design it can be inferred, which saves bandwidth. I'm not
claiming that's a mega-win, but I do think it might be needed for
some of the device-sends-one-message-per-day scenarios if those
are also using e.g. some lpwan radio technology.

Maybe the thing we could agree at this stage is that the cid scheme
has to be usable in that one-message-per-day scenario and needs to
provide some way that such messages aren't easily linkable based on
cids. (Which is useful if/when the 5-tuples don't provide linkage.)
Personally I do think a hash-chain based scheme may be needed to
meet that requirement, but I may well be wrong of course, as that
happens quite a lot:-)

Cheers,
S.

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