On 22/10/17 17:04, Eric Rescorla wrote: > 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.
Not sure tbh, ISTM there's a bunch of challenges in trying to use the kind of lpwan technologies being developed with DTLS, with cid just being one of those. But time will tell I guess, and that's a different discussion. > 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) > Fair enough - I can buy that the last above suffers when one tries to satisfy all the rest. Maybe that means a WG draft ought have an applicability statement section that captures the scenarios where that particular cid extension is suitable. I'll be sad though if the end result is to sacrifice unlinkability which I fear will be the likely outcome in practice. > 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. Again, maybe some applicability text as per the above would make it clearer that the draft is describing one (though hopefully the most commonly useful) scheme and that others may be needed in other situations. Cheers, S. PS: In case it helps, with the additions discussed earlier and above, and with the understanding that exploring other cid schemes for cases where this one isn't fully satisfactory isn't ruled out, I think this draft would be a fine starting point for a WG document. > > > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
