> On 27 Jan 2022, at 20:06, Brian Trammell (IETF) <[email protected]> wrote: > > Greetings, all, > > This proposal addresses my concerns about padding implementation; thanks! One > point below.
Hi All, Many thanks for all the feedback on this. The PR is merged with the nits fixed. Regards Sara. > >> On 27 Jan 2022, at 20:03, Daniel Kahn Gillmor <[email protected]> wrote: > > <snip> > >> On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote: >> >>> Further, traffic analysis threats are not limited to packet lengths, >>> as section 9.5 acknowledges. Is there any equivalent MUST guidance >>> regarding stream frame timing for traffic analysis resistance that >>> could be given here? >> >> This is a great question, and i am unaware of any work that this draft >> could point to that would address temporal traffic analysis in a DNS >> resolution context. >> >> I think the first order traffic analysis concerns that would be worth >> tackling are largely from the responder (server) side -- it gets even >> more complex if want to address *when* a DNS client should make a given >> request. > >> In particular, if DoQ is used in authoritative deployments, i'd expect >> most server responses (served locally from an ingested zonefile) to have >> roughly the same temporal delay. I could imagine some noticeable >> temporal differences between "popular" and unpopular records for >> authoritative servers that do live DNSSEC signing or NSEC5-style >> proof-of-nonexistence that requires cryptographic work on behalf of the >> authoritative. >> >> From the client side of authoritative DoQ, it's conceivable that some >> temporal traffic analysis resistance could be gained by thinking about >> how recursive resolvers can best prefetch to keep their cache hot. > > Indeed, from a timing correlation standpoint the state of the art is “use a > giant recursive with multiple egress to hide in a large anonymity set”, which > this is a generalization of…. > >> But I suspect this is in the realm of "more research needed", and isn't >> appropriate for this draft. > > Yep. The question just popped into my head while reviewing. > >> If anyone has any informative pointers that they think are worth >> including as a nod toward temporal traffic analysis, i'd be interested >> in reviewing them, but I don't think they should block this draft's >> progress. > > To be clear, I also don’t think this question should block publication, but > I’d encourage the working group to consider timing guidance for DNS privacy. > Indeed, some of the more general questions could be referred to PEARG? Most > of these techniques should be equally applicable, with varying degrees of > implementation difficulty depending on the transport. > > Thanks, cheers, > > Brian > > >> >> --dkg >> _______________________________________________ >> Tsv-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tsv-art > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
