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

Magnus Nyström <magnusn@gmail.com> Tue, 14 August 2018 18:42 UTC

Return-Path: <magnusn@gmail.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 CAD2212785F; Tue, 14 Aug 2018 11:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hMLaQt8G4WXT; Tue, 14 Aug 2018 11:42:38 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E3D124BE5; Tue, 14 Aug 2018 11:42:38 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id y4-v6so9481307pgp.9; Tue, 14 Aug 2018 11:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j3lwMGn8Xlooy1zfrf1svh+lOWhqw4fKXZPLIm8MMIU=; b=XM1pf8WcUMdOvsktqRl7d8amGBfw9X+qlMBMtdj5gKVhvqjWsVf5/a+jfOKNe2/sgF f+JTdmLVKMjoG1HluOeyy9d06GiuFtG2glELRmTCTG6Km78KYkCxCqqHaSbmXsfHIo2x JR53HY1gqVnOqg6eMf7DEEiHFtejtZVLe5l6h18aTPioVxGTCu5NiBwc1VkC29AvakJk d7g0LgN4qy/mCFh5E79TzuWiz0bePsue2u8Og9wBcqrcJot6Pmlu9y/Xe6x9S5FjP0NJ MdZEl6rSHo5cD41obQzFdH6B5gf9Kh2TahCMlF3gEs/fxFd9fErDArM+VYBTH0B9hQsq P3JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j3lwMGn8Xlooy1zfrf1svh+lOWhqw4fKXZPLIm8MMIU=; b=HBx9ovBUPHe8Nu6pVD1NZ2ojdnWrtMSIq6HbejaWgcKAhTqNfVKMcLO+YUHswRCJVb hPDJBJ6TNTcyvIoY0RYk8/UzHRMRnwFZM5GmgOotCrDnJinShMPmNDLrbxJZY6awWO87 YPeEDneIIhMIgRhNPz1JJCTSr+DyieM9Lk6kE62kvikBPAIX8320CYLL+/F+QQpY9kXl rTfLwTKdrK5P4TFGjwKbxaZsrgRnkBBcDXSHOn9tK5t6D7lBtcjAFofbHml2QEe3It6N trrjVGPiag0n9VcaMKQVoVgLNjQ6fIEKA//8225vubWfrGWjW8FReKVBR1kzJKUzkNzC rmag==
X-Gm-Message-State: AOUpUlHfd42a/2dWL7d7bfIroG1nVMxZjYvJUobKoq63ihJCtIdVQN12 MkvbEve8ExT4WfSTlVpsYsWMbX/reRncInbgCR4=
X-Google-Smtp-Source: AA+uWPyLhOSjTEaj3BUQC+U4NBvlsSObtMCWpg6znGvivjHczLrha6SEJ1t4QyfWRxmNepmA9MSXBGkBy4laACus3zM=
X-Received: by 2002:a63:6c05:: with SMTP id h5-v6mr22423588pgc.367.1534272157741; Tue, 14 Aug 2018 11:42:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:bd0f:0:0:0:0 with HTTP; Tue, 14 Aug 2018 11:42:37 -0700 (PDT)
In-Reply-To: <CAOdDvNq-17DX2FqG9vZRLQmgbtG2mtPaovwMEtB2nXk7sy_TcQ@mail.gmail.com>
References: <CADajj4Y6-iNNg1XOW4kZO8kGE3sEOWie6RNcgMasyiKebkuNHw@mail.gmail.com> <CAOdDvNq-17DX2FqG9vZRLQmgbtG2mtPaovwMEtB2nXk7sy_TcQ@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Tue, 14 Aug 2018 11:42:37 -0700
Message-ID: <CADajj4aE8zBiS__mTgn0weokjp13Xpf08Nj2YyfSKezW-0S9=g@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-doh-dns-over-https@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f37abe05736992ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/v0GdMUHuSQyOH8NK4KUfhNN-nlc>
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 18:42:41 -0000

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 <pmcmanus@mozilla.com>
wrote:

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


-- 
-- Magnus