Re: [Doh] [Ext] assorted things

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 June 2018 14:42 UTC

Return-Path: <paul.hoffman@icann.org>
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 F1B151310BE for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 BPYQ4-eUYiDu for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 07:42:26 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8606C131002 for <doh@ietf.org>; Tue, 5 Jun 2018 07:42:26 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 5 Jun 2018 07:42:24 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 5 Jun 2018 07:42:24 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: bert hubert <bert.hubert@powerdns.com>
CC: "doh@ietf.org" <doh@ietf.org>
Thread-Topic: [Ext] [Doh] assorted things
Thread-Index: AQHT/MnAMTM+RUINW0SyNYIuXR3MXKRSMpmA
Date: Tue, 05 Jun 2018 14:42:23 +0000
Message-ID: <95D1F35A-B7C4-4AF9-B682-CA1C17DCE34F@icann.org>
References: <20180605123541.GB29047@server.ds9a.nl>
In-Reply-To: <20180605123541.GB29047@server.ds9a.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; boundary="Apple-Mail=_54AB44F6-906C-477A-8FF6-B6FDB0FD36C5"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Qoas8_B9A2INuZ0cPlY57caSZBw>
Subject: Re: [Doh] [Ext] assorted things
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
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, 05 Jun 2018 14:42:29 -0000

On Jun 5, 2018, at 5:35 AM, bert hubert <bert.hubert@powerdns.com> wrote:
> 
> Hi everyone,
> 
> I'm going through -10 with fresh eyes, so I may be discovering some parts
> that are not obvious to the outsider, or at least this reader. 
> 
> This paragraph in 4 seems to be important, but I can't figure out what it is
> trying to achieve:
> 
>   A DNS API client MUST NOT use a different URI simply because it was
>   discovered outside of the client's configuration, or because a server
>   offers an unsolicited response that appears to be a valid answer to a
>   DNS query.  This specification does not extend DNS resolution
>   privileges to URIs that are not recognized by the DNS API client as
>   configured URIs.  Such scenarios may create additional operational,
>   tracking, and security hazards that require limitations for safe
>   usage.  A future specification may support this use case.
> 
> Does this say "don't just use any URI"?

It says "don't use a URI that is not configured".

>  What are 'DNS resolution
> privileges'?

The equivalent of "a DNS open resolver that you discovered by accident".

> Is this about disallowing javascript to send out random DNS
> queries? 

No. It is about them sending out queries to servers not in their configuration.

> 
> This sentence:
> 
>   Some of these non-successful HTTP responses (e.g., redirects or
>   authentication failures) could mean that clients need to make new
>   requests to satisfy the original question.
> 
> I would recommending teeth to this. Naive implementations may decide to not
> follow 3xx codes. I would recommend making this explicit with a MUST.

Good catch. We assume that developers of DNS API clients will follow HTTP semantics here, but we didn't say so explicitly.

> Also,
> it may be worth it to explicitly say if authentication is in our out of
> scope.

No, definitely not. Authentication is completely in scope.

> Here it is a bit uncertain if you'd ever prompt a user for a
> username/password for doing DNS resolution. 

HTTP authentication does not require a UI at all.

> 
> In 6.3 "Server Push":
>   For HTTP server push ([RFC7540] Section 8.2) extra care must be taken to
>   ensure that the pushed URI is one that the client would have directed the
>   same query to if the client had initiated the request.
> 
> This means an API server is free to send responses to DNS queries we haven't
> seen yet?  And should a client do something with that?  Or can it ignore the
> pushed records?

Yes; not "should" but "may"; yes. This is all well-defined in HTTP/2.

--Paul Hoffman