[Doh] assorted things

bert hubert <bert.hubert@powerdns.com> Tue, 05 June 2018 12:35 UTC

Return-Path: <bert@hubertnet.nl>
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 4D210131006 for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 05:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] 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 S3x68NDhW0Fp for <doh@ietfa.amsl.com>; Tue, 5 Jun 2018 05:35:50 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5BA130FFF for <doh@ietf.org>; Tue, 5 Jun 2018 05:35:50 -0700 (PDT)
Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 385EE9FB55 for <doh@ietf.org>; Tue, 5 Jun 2018 12:35:41 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 82CBEAC54A3; Tue, 5 Jun 2018 14:35:41 +0200 (CEST)
Date: Tue, 5 Jun 2018 14:35:41 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: doh@ietf.org
Message-ID: <20180605123541.GB29047@server.ds9a.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/CNH64-OOAiYmlHYMZNeLmuW8lg4>
Subject: [Doh] 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 12:35:52 -0000

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"?  What are 'DNS resolution
privileges'? Is this about disallowing javascript to send out random DNS
queries? 

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. Also,
it may be worth it to explicitly say if authentication is in our out of
scope. Here it is a bit uncertain if you'd ever prompt a user for a
username/password for doing DNS resolution. 

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?

	Bert