Subject: [Last-Call] Tsvart last call review of draft-ietf-dprive-dnsoquic-08

From: Brian Trammell via Datatracker <[email-masked]>
Date: Mon, 24 Jan 2022 07:05:18 -0800

Reviewer: Brian Trammell
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

This document is a mature and straightforward mapping of DNS over QUIC, 
modeling a QUIC connection as equivalent to DNS over TCP with one query
per stream. 0-RTT and fallback design choices are reasonable and
well-explained. Security and privacy considerations are well-presented. 
All in all, a very good example of an application mapping over QUIC.

I have only a few nits here:

Editorial nits:

- in section 5.3.1, is STOP_SENDING spelled "STOP_SENDING" 
or "Stop Sending"? Please choose one.

- "These privacy issues are detailed in Section 9.2 and Section 9.1" 
is a weird order; please swap.

Content nit:

I understand the intent behind "Implementations MUST protect against the
traffic analysis attacks described in Section 9.5 by the judicious injection of
padding"; however (1) there is no interoperability risk from failing to comply
with this restriction, and (2) as an implementor, it would not be clear to me
how to prove my padding injection was "judicious". 

There is a reference to an experimental RFC 8467 that presumably defines
acceptable padding policies, but it is referenced as "should consider".

I would recommend one of the three following remedies:

- change this to a SHOULD (since verifying compliance is impossible as phrased),
- add a normative downref to 8467 and make it clear that that reference defines 
padding policies considered compliant, or
- provide some other guidance implementors can use do determine whether
they are padding enough to be considered compliant.

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?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Jan 2022 10:32:55 -1000

Thanks for the review, Brian.

We have been going back and forth on the padding requirements, and the 
current text is specifically written to avoid a downward reference to 
RFC 8467. You are making a good arguments that it is hard for 
implementers to comply with a requirement that they MUST pad if there is 
no specific guidance about how to pad. On the other hand, I think that 
we should not delay publication until getting definitive agreement on 
the appropriate padding policy. For example, we would have to resolve 
the tension between application specific padding, with a goal to hide 
which DNS names are being queried, and generic transport level padding, 
with a goal to prevent traffic analysis from distinguishing between DoQ 
and other applications. So, I am inclined to just replace MUST by 
SHOULD, and leave it at that. That's one of your proposed remedies,  but 
I wonder whether others might object.

-- Christian Huitema

On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Jan 2022 13:17:39 +0000

Hi Brian, 

Thanks for the review, and as Christian said the padding question has been a point of discussion.

I’m personally comfortable with a downref to RFC 8467 with text to support why this is done as you suggest. Multiple studies have shown just how easy traffic analysis is without any padding - we could actually cite one of the more recent ones. RFC 8467 is implemented for stub-recursive DoT in most open source software and is in use by major recursive operators.  For me this approach mitigates the immediate risk of exposing DNS names - preventing traffic analysis from identifying DoQ is a much longer term goal (and requires ECH). 

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

Regards

Sara

> On 26 Jan 2022, at 20:32, Christian Huitema <[email-masked]> wrote:
> 
> We have been going back and forth on the padding requirements, and the current text is specifically written to avoid a downward reference to RFC 8467. You are making a good arguments that it is hard for implementers to comply with a requirement that they MUST pad if there is no specific guidance about how to pad. On the other hand, I think that we should not delay publication until getting definitive agreement on the appropriate padding policy. For example, we would have to resolve the tension between application specific padding, with a goal to hide which DNS names are being queried, and generic transport level padding, with a goal to prevent traffic analysis from distinguishing between DoQ and other applications. So, I am inclined to just replace MUST by SHOULD, and leave it at that. That's one of your proposed remedies,  but I wonder whether others might object.
> 
> -- Christian Huitema
> 
>

---

From: Allison Mankin <[email-masked]>
Date: Thu, 27 Jan 2022 08:36:42 -0500

I share Sara's position.

On Thu, Jan 27, 2022 at 08:18 Sara Dickinson <[email-masked]> wrote:

> I’m personally comfortable with a downref to RFC 8467 with text to support
> why this is done as you suggest. Multiple studies have shown just how easy
> traffic analysis is without any padding - we could actually cite one of the
> more recent ones. RFC 8467 is implemented for stub-recursive DoT in most
> open source software and is in use by major recursive operators.  For me
> this approach mitigates the immediate risk of exposing DNS names -
> preventing traffic analysis from identifying DoQ is a much longer term goal
> (and requires ECH).
>
> I’ve had a first pass at a PR making RFC8467 normative here:
> https://github.com/huitema/dnsoquic/pull/143
>
> Regards
>
> Sara
>
>
> current text is specifically written to avoid a downward reference to RFC
> 8467. You are making a good arguments that it is hard for implementers to
> comply with a requirement that they MUST pad if there is no specific
> guidance about how to pad. On the other hand, I think that we should not
> delay publication until getting definitive agreement on the appropriate
> padding policy. For example, we would have to resolve the tension between
> application specific padding, with a goal to hide which DNS names are being
> queried, and generic transport level padding, with a goal to prevent
> traffic analysis from distinguishing between DoQ and other applications.
> So, I am inclined to just replace MUST by SHOULD, and leave it at that.
> That's one of your proposed remedies,  but I wonder whether others might
> object.
> >
> > -- Christian Huitema
> >
> >

---

From: Brian Haberman <[email-masked]>
Date: Thu, 27 Jan 2022 09:05:04 -0500

I support the additional text on padding.

As a process note, I believe we will need to re-issue the IETF Last Call 
to allow for the discussion of the down-ref to 8467.

Regards,
Brian

On 1/27/22 8:36 AM, Allison Mankin wrote:
>>>> well-explained. Security and privacy considerations are well-presented

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Jan 2022 14:03:09 -0500

> 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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 27 Jan 2022 21:06:41 +0100

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-masked]> wrote:

<snip>

> 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….

> appropriate for this draft.

Yep. The question just popped into my head while reviewing.

> in reviewing them, but I don't think they should block this draft's

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

> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Allison Mankin <[email-masked]>
Date: Thu, 27 Jan 2022 19:30:02 -0500

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-masked]>
wrote:

> 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….
>
> 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

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 28 Jan 2022 10:50:04 +0000

> On 27 Jan 2022, at 20:06, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, all,
> 

Hi All, 

Many thanks for all the feedback on this. The PR is merged with the nits fixed. 

Regards

Sara.