> On 27 Jan 2022, at 20:06, Brian Trammell (IETF) <ietf@xxxxxxxxxxx> 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 <dkg@xxxxxxxxxxxxxxxxx> 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 >> Tsv-art@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tsv-art > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
