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

Patrick McManus <pmcmanus@mozilla.com> Tue, 14 August 2018 14:59 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5709912F18C; Tue, 14 Aug 2018 07:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkiHsaA05uIM; Tue, 14 Aug 2018 07:59:04 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBD812426A; Tue, 14 Aug 2018 07:59:04 -0700 (PDT)
Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id AF2633A02F; Tue, 14 Aug 2018 10:59:02 -0400 (EDT)
Received: by mail-oi0-f46.google.com with SMTP id v8-v6so34119761oie.5; Tue, 14 Aug 2018 07:59:02 -0700 (PDT)
X-Gm-Message-State: AOUpUlGJoGbbtvQ/jCnPz4cMGu2koyKN9HpLKxSog0RTL53MDHdEEeWN JylbLK4zRSyS5ubS0fkloW20lvEJj0Q9C5TgPII=
X-Google-Smtp-Source: AA+uWPzcrQ6PZKOugjQ0i9Qi8JsFhvHmvTg9l8k4D5Gkypoq+NAnHy0aSGQfs/xJAgsIyMvVv+xQg++mZOC/+NyDGCI=
X-Received: by 2002:aca:31c6:: with SMTP id x189-v6mr24096667oix.213.1534258742427; Tue, 14 Aug 2018 07:59:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 07:59:01 -0700 (PDT)
In-Reply-To: <CADajj4Y6-iNNg1XOW4kZO8kGE3sEOWie6RNcgMasyiKebkuNHw@mail.gmail.com>
References: <CADajj4Y6-iNNg1XOW4kZO8kGE3sEOWie6RNcgMasyiKebkuNHw@mail.gmail.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Tue, 14 Aug 2018 10:59:01 -0400
X-Gmail-Original-Message-ID: <CAOdDvNq-17DX2FqG9vZRLQmgbtG2mtPaovwMEtB2nXk7sy_TcQ@mail.gmail.com>
Message-ID: <CAOdDvNq-17DX2FqG9vZRLQmgbtG2mtPaovwMEtB2nXk7sy_TcQ@mail.gmail.com>
To: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-doh-dns-over-https@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056071f0573667350"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uHWhIyMHQYUQsf3cs_mrymuynx0>
Subject: Re: [secdir] Secdir review of draft-ietf-doh-dns-over-https
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 14:59:07 -0000

Hi Magnus, thanks for the review.

On Tue, Aug 14, 2018 at 2:42 AM, Magnus Nyström <magnusn@gmail.com> 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 <magnusn@gmail.com> 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
>
>