Re: [TLS] Connection ID Draft

[Eric Rescorla <[e-mail]>]

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

>
>
> On 22/10/17 16:41, Eric Rescorla wrote:
> >
> >> 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.
>
> Sorry, I'm not sure what you mean there. Are you saying that you think
> the above requirement can't be met by a generally usable scheme?
>
> I agree that not all scenarios need to meet the req posited above.
>
> I'd worry that if DTLS1.3 can't meet the above requirement then folks
> will invent something that does, which may be worse than using DTLS
> in a bunch of cases. OTOH, one could equally, and maybe fairly, argue
> that DTLS really doesn't scale down quite that far, which'd I guess
> argue that there's a need for some other security protocol for those
> situations.
>

It's not a matter of DTLS versus non-DTLS. I am unaware of any method
of providing conn-IDs that simultaneously meets the requirements of:

- Unlinkability
- Being able to survive multiple conn-ID changes in one round-trip
  (which is implicit in both the one-packet per day and the unknown
  address changes scenarios)
- Low bandwidth
- Good receiver-side scaling (both state and computational)

This is a generic problem, not one limited to DTLS. And as I said earlier,
to the extent to which we either need specific schemes that meet different
subsets of these requirements or we come up with a better generic scheme,
the extension-based approach accommodates it.


PS: I fully accept your point that purely napkin-based schemes aren't
> good enough and if those're the only kind of hash-chain based proposals
>
seen, then the WG oughtn't go for one of those.
>

We've seen others, and they fail the receiver-side scaling test, IMO

-Ekr