Subject: [secdir] Secdir review of draft-ietf-doh-dns-over-https

From: Magnus Nyström <[email-masked]>
Date: Mon, 13 Aug 2018 23:42:25 -0700

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes a protocol for sending DNS queries, and
receiving DNS responses, over HTTPS. The document reads well, has rich
privacy and security considerations sections and includes numerous
examples which is very helpful.

Comments:

Section 3: Why remove this section altogether before publication? It
seems it provides some useful information on the background for why
the protocol is designed the way it is?

Section 4: Was the "A DoH client MUST NOT use a different URI simply
because it was discovered outside of the client's configuration"
intended to state: "A DoH client MUST NOT use URIs discovered outside
of the client's configuration"? The latter seems clearer.

Section 10: It is stated that HTTP/2 implementations will benefit from
the TLS 1.2 profile developed for HTTP/2. How about HTTP/1.1
implementations? Should there be a TLS profile for them? Also, any
particular TLS 1.3 considerations - e.g, 0-RTT and the use of the GET
option here?

Editorial:
- It seems like the references section needs some updates - e.g., I
found references to RFC 7828 and RFC 6891 in the text but not in the
references section.

-- 
-- Magnus

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Aug 2018 10:59:01 -0400

Hi Magnus, thanks for the review.

On Tue, Aug 14, 2018 at 2:42 AM, Magnus Nyström <[email-masked]> wrote:

> I

It does reflect the thinking of the authors to help guide the rest of the
protocol document and I believe it to be accurate - but as it hasn't been
intended for publication it hasn't received the scrutiny the rest of the
document has I would be worried about completeness in particular. It was
meant to help the working group keep those things in mind during design,
the intended audience was never to make declarative statements to the
implementer.

> of the client's configuration"? The latter seems clearer.
The language there is meant to emphasize accidental discovery (e.g. http/2
push of DoH). Its not trying to go into all the other potential modes of
more intentional discovery.

> implementations? Should there be a TLS profile for them?

the profile in question is part of http, not part of doh (other than by
inclusion). An H1 profile would not be backwards compatible.

> Also, any
The normal HTTPS considerations thankfully apply; including
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ (in rfc ed
queue) but not in any special way for DoH compared to other HTTP.

> found references to RFC 7828 and RFC 6891 in the text but not in the
I believe this is corrected already due to other inputs. Thanks!

---

From: Magnus Nyström <[email-masked]>
Date: Tue, 14 Aug 2018 11:42:37 -0700

Thanks Patrick.
Perhaps the current Section 3 could be moved to an Appendix to still
capture some of the reasoning behind the protocol design; it is up to you
of course.

On the language in Section 4, perhaps then the language could be changed
(for clarity) to:

"A DoH client MUST NOT use a URI Template unintentionally discovered (e.g.,
through HTTP/2 push of DoH)."  ( Possibly amended with: "A DoH client MUST
only use URI Templates being part of their configuration.")

That's all,

-- 
-- Magnus

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Aug 2018 15:13:26 -0400

On Tue, Aug 14, 2018 at 2:42 PM, Magnus Nyström <[email-masked]> wrote:

> "A DoH client MUST NOT use a URI Template unintentionally discovered
> (e.g., through HTTP/2 push of DoH)."  ( Possibly amended with: "A DoH
> client MUST only use URI Templates being part of their configuration.")
>
>
yep.. we'll add a parenthetical "such as http/2 push" to help folks
understand that's an important case.