Re: [TLS] Connection ID Draft

[Eric Rescorla <[e-mail]>]

On Sun, Oct 22, 2017 at 8:23 AM, Stephen Farrell <[e-mail]>
wrote:

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

I'd be fine with adding that sort of text.


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

I didn't say that it didn't differ. I said I didn't think it had better
linkability
properties.


In the draft the new connection ID has to be sent explicitly, but
> in this design it can be inferred, which saves bandwidth.


That's not obviously true, because the CIDs in your case need to
be larger to avoid collision problems.


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.


I think that's a requirement in some cases but not others. It might be
best to settle for the others.


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

That's clearly not true in the case where messages are symmetrical, as
each side can provide a new connection ID with each message it sends.
In fact, we considered just such a design for QUIC before concluding
it was impractical.

And note that in the case where you are actually sending one un-acked
message per day, then it's actually quite easy to have significant packet
loss in which case you run into the scaling problems I mentioned in my
previous message.

Again, I really would invite you to try to produce a fully worked out
proposal,
as its precisely the exercise of trying to do so that led us to this
design. As
none of the options are really ideal, it's quite easy to find deficiencies
in
any particular design, especially when the alternative is something that
is at the napkin stage, and so has deficiencies which are yet to be
determined.

-Ekr




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