Re: [Doh] WGLC #2

Sara Dickinson <sara@sinodun.com> Tue, 22 May 2018 15:37 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4C12E894 for <doh@ietfa.amsl.com>; Tue, 22 May 2018 08:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 tjFZtl8yHm1e for <doh@ietfa.amsl.com>; Tue, 22 May 2018 08:37:34 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C2C12741D for <doh@ietf.org>; Tue, 22 May 2018 08:37:34 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::] (port=63855) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1fL9Lt-0007Tu-3e; Tue, 22 May 2018 16:37:33 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_85DDB95B-F19B-4A2B-A285-01CBAAFACB26"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 22 May 2018 16:37:23 +0100
In-Reply-To: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com>
Cc: DoH WG <doh@ietf.org>
To: "Hewitt, Rory" <rhewitt=40akamai.com@dmarc.ietf.org>
References: <CAHbrMsCxkogJ-fzubf7cPgvbeGAhWUFKV3crrmn4ee6=fDnqwQ@mail.gmail.com> <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-BlackCat-Spam-Score: 3
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/E174hErNLYngEeBobm7Y_Tc5zLU>
Subject: Re: [Doh] WGLC #2
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 May 2018 15:37:37 -0000


> On 21 May 2018, at 21:41, Hewitt, Rory <rhewitt=40akamai.com@dmarc.ietf.org> wrote:
> 
> I know I brought this up in
> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agreed to
> leave it, but I see that Mateusz subsequently brought it up in
> https://www.ietf.org/mail-archive/web/doh/current/msg00557.html...
> 
> I would really like to see Section 4 (Selection of DNS API Server) moved to be
> within Section 9 (Security Considerations), perhaps as a subsection (9.1:
> Selection of DNS API Server)

The reason I think it is useful to have Section 4 is that Section 6.3 (Server Push) discusses which URI’s pushes should be accepted from and so is implicitly talking about which servers to use. However _if_ section 4 is moved I think there should at least be a reference in section 6.3 to Section 9.


2 other comments:

1) I previously asked if this spec required that a DNS API Sever should only be used if authentication of the TLS connection was successful. I got conflicting answers from Paul and Martin (‘No we can’t say that’ vs ‘authentication is critical and implicit’) and don’t see anything in this version that resolves this. I know there is other work attempting to address this issue (and more) but the lack of clarity in this document on the topic is still an issue for me. I’d still like to see a single sentence that either
- makes clear the requirement (preferable) or
- states that this is out of scope


2) “If a client of this protocol encounters an HTTP
   error after sending a DNS query, and then falls back to a different
   DNS retrieval mechanism, doing so can weaken the privacy and
   authenticity expected by the user of the client.”

What does authenticity mean here - data integrity or DNSSEC authentication? If it is the latter I would argue to remove it because DNSSEC and transport choice are orthogonal.

Sara.