Re: [DNSOP] draft-sah-resolver-information (revised)

"John Dickinson" <jad@sinodun.com> Mon, 03 June 2019 11:55 UTC

Return-Path: <jad@sinodun.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEF3120092 for <dnsop@ietfa.amsl.com>; Mon, 3 Jun 2019 04:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.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 wa-OWb54eQDd for <dnsop@ietfa.amsl.com>; Mon, 3 Jun 2019 04:55:22 -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 1A072120004 for <dnsop@ietf.org>; Mon, 3 Jun 2019 04:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=yskbU82ezfgEg/U57sWJcWr/Im2YiczGuSh1rde9X00=; b=jxaoR3h/X10WilQeAfvfm3yRLq QYkZ8DrkPkEnCrGfwE7ilGoO2Qjk+NIGKwL+DZ238jZr6/6wXbJ5d6/bjwKYIqN7NA/T0j7EGUJgL J8Cte1lH4La4dpgrUnMyo7lOXTHOfpjAPs5hE2PBt/uhpoX7oR+4hhGrQsrWXM944/35b+nVnxov4 Sm/cDB8pcxTvyN6ByWaP5akyluGh0BOelLvjaQX0z49FQJJtsFaH2h2LBaJtdz4Yaa+iG+vz/TXeb 5YlRhjhaWWzx51do8xvtbm6vPQUQ2Rbuvn/CPX/He7DSgqfh9GbrfQFww3MVve734nf3zYjd5qXTx 1Qu0engw==;
Received: from [2001:b98:204:102:fffa::4e86] (port=49743 helo=[192.168.12.13]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <jad@sinodun.com>) id 1hXlYe-0004H5-72; Mon, 03 Jun 2019 12:55:20 +0100
From: John Dickinson <jad@sinodun.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Date: Mon, 03 Jun 2019 12:52:28 +0100
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <00C80F63-AF03-4960-B602-001BE951F2D5@sinodun.com>
In-Reply-To: <0F4F5B08-A81B-48D4-AAFE-F89FEE980F9A@icann.org>
References: <3BCCE28D-17C6-4367-A9C3-D0DCF56AB03A@icann.org> <alpine.LRH.2.21.1905151256480.22294@bofh.nohats.ca> <C3668C33-E3DB-4267-AF5B-FDC46262CC8F@icann.org> <alpine.LRH.2.21.1905152258340.18222@bofh.nohats.ca> <0F4F5B08-A81B-48D4-AAFE-F89FEE980F9A@icann.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_636878AB-50CD-4C49-BAE2-AF862CDB8CB3_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-BlackCat-Spam-Score: -21
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HUpq9tvEMU-krlFmac1Pq7r_JrI>
Subject: Re: [DNSOP] draft-sah-resolver-information (revised)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 11:55:25 -0000

On 22 May 2019, at 23:30, Paul Hoffman wrote:

> Greetings again. Based on the input from the DNSOP and DOH lists, we revised draft-sah-resolver-information. We also created a new draft, draft-sah-resinfo-doh, to cover the main use case we have for getting information from a resolver, namely to get the DoH URI template and authentication information.
>
>> From the mailing list traffic, it seems like some of y'all only care about getting resolver information from DNS (hopefully DNSSEC-signed), while others are fine to use HTTPS with web PKI authentication, particularly when DNSSEC signing is not possible. We have left both methods in the main draft.
>
> We encourage more input.
>
> --Paul Hoffman
>
> ======
>        Title           : DNS Resolver Information Self-publication
>        Authors         : Puneet Sood
>                          Roy Arends
>                          Paul Hoffman
> 	Filename        : draft-sah-resolver-information-01.txt
> 	Pages           : 9
> 	Date            : 2019-05-22
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
>

Reference to SUDN in Introduction is no longer needed.

DNS-over-TLS and DNS-over-HTTPS are both abbreviated to DoT in the Security Considerations

Section 4 P3 s/returen/return/

Section 4 and 5.2 are a bit hard to follow (maybe I need more caffeine). I would suggest that you use the term key-value pair in place of name-value pair. Using the word name in DNS docs is bound to lead to confusion.

Also I was a bit confused by

4: “All names in the returned object MUST be defined in the IANA registry
   or begin with the substring "temp-“” and
   “As defined in Section 5.2, the
   IANA registry will not register names that begin with "temp-", so
   these names can be used freely by any implementer”

5.2: “Name: The name to be used in the JSON object.  This name MUST NOT
   begin with "temp-".

until I reread the words “or begin with the substring "temp-“” I think the could be clearer, something like:

All keys in the returned object MUST either be defined in the IANA registry or if for local use only they MAY begin with the substring "temp-“ since IANA registry will not register names that begin with "temp-“.

Finally, section 2

“Note that the answer given by the resolver cannot be validated with DNSSEC.”
Whilst I understand the reasons, is it reasonable that we are still trying to standardise responses that can not be signed? Is it not time to start mandating that DNSSEC is a MUST for all DNS responses and that includes ones sent over DoT and DoH (and any future DoFOO)? At the very least, there should be very detailed discussion in the security considerations section about the reasons for and impact of not using DNSSEC, which you have done, although I don’t like text that says “if it is using DoT it will know if the communication is authenticated (DoH is always authenticated)”

regards
John

John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.