On Sun, Oct 22, 2017 at 8:50 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
