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) <ietf@xxxxxxxxxxx> 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 <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
