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

[Patrick McManus <[e-mail]>]

Hi Magnus, thanks for the review.

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

> I
> 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?
>

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.


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


> 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?


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
> particular TLS 1.3 considerations - e.g, 0-RTT and the use of the GET
> option here?
>
>
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.


> 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.
>
>
I believe this is corrected already due to other inputs. Thanks!


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

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