Re: [Tsv-art] [dns-privacy] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2022-01-27 13:17:39 +0000, Sara Dickinson wrote:

> I’ve had a first pass at a PR making RFC8467 normative here:
> https://github.com/huitema/dnsoquic/pull/143

Modulo a few minor editorial nits (which i've noted on this PR), i
support this change as well.  Padding defenses are simple, cheap, and a
bare minimum for defending the privacy of encrypted DNS queries.

> preventing traffic analysis from identifying DoQ is a much longer term
> goal (and requires ECH).

I also agree that this kind of defense is currently out of reach; we
don't only need ECH, we would need to think about the IANA UDP port
number registration (853 ≠ 443).  We will at some point need to tackle
these issues so that the network intermediary isn't able to distinguish
categories of network service, but we shouldn't delay this document for
that fix.

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.

But I suspect this is in the realm of "more research needed", and isn't
appropriate for this draft.

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.

        --dkg