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
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
