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

[Magnus Nyström <[e-mail]>]

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,


On Tue, Aug 14, 2018 at 7:59 AM, Patrick McManus <[e-mail]>
wrote:

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


-- 
-- Magnus