I second referring the problem to PEARG. I think there are tractable though complex elements
On Thu, Jan 27, 2022 at 15:06 Brian Trammell (IETF) <[email protected]> wrote: > Greetings, all, > > This proposal addresses my concerns about padding implementation; thanks! > One point below. > > 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
