IETF Logo Mail Archive

Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information

Paul Hoffman <paul.hoffman@icann.org> Thu, 11 July 2019 00:25 UTC

Return-Path: <paul.hoffman@icann.org>
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 9500F120059 for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 17:25:08 -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, SPF_HELO_NONE=0.001, 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 irh7Xx32ksVu for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 17:25:06 -0700 (PDT)
Received: from mail.icann.org (out.west.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 BEC6412004D for <dnsop@ietf.org>; Wed, 10 Jul 2019 17:25:06 -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.1473.3; Wed, 10 Jul 2019 17:25:04 -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.1473.005; Wed, 10 Jul 2019 17:25:04 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: tirumal reddy <kondtir@gmail.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] Request for adoption: draft-sah-resolver-information
Thread-Index: AQHVN38VaYwxmJTSq0Cz4rLHVMCEtA==
Date: Thu, 11 Jul 2019 00:25:03 +0000
Message-ID: <76A15C99-20BB-4AC8-9F34-D690D27B81EA@icann.org>
References: <F00B09EC-24D8-40C1-8A6C-86C2FD63A062@icann.org> <CAFpG3gcLF-tYJtiiV8kDKHa-rdSb=DQqLYuV-n+XX-PG5qEWmw@mail.gmail.com>
In-Reply-To: <CAFpG3gcLF-tYJtiiV8kDKHa-rdSb=DQqLYuV-n+XX-PG5qEWmw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <093C2AD5A3B5C24197ED36E08CC12184@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zCrPCd_M71MJz4rJzrllkeeg1KU>
Subject: Re: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
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: Thu, 11 Jul 2019 00:25:08 -0000

On Jul 9, 2019, at 3:46 AM, tirumal reddy <kondtir@gmail.com> wrote:
> My comments below:
> 
> 1) Unless a DNS request for <reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO,
>    or a subdomain, as described in Section 2 is sent over DNS-over-TLS
>    (DoT) [RFC7858] or DNS-over-HTTPS (DoH) [RFC8484], or unless the
>    <reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
>    response is susceptible to forgery.
> 
> Comment> If the stub resolver is already using DoH with the recursive resolver, why does it have to determine the URI template of the DoH server?

One example is that the stub or browser may want to change DoH servers, such as if it has discovered one that has a better security policy.

> 2) DHCP clients typically have no secure and trusted relationships to DHCP servers, how will the client know it is communicating with the recursive resolver hosted in the attached network ?

It will not. This has always been the problem with DHCP, and efforts to make DHCP authenticated have not borne fruti.

> 3)  
>    In the future, DHCP and/or DCHPv6 and/or RA may have options that
>    allow the configuration to contain the domain name of a resolver.  If
>    so, this can be used for matching the domain name in the TLS
>    certificate.
> 
> Comment> Same comment as above, Please see https://tools.ietf.org/html/rfc8310#section-7.3.1 [tools.ietf.org]

That document does not preclude future configuration options. I don't see any reason for this spec to do so.

> 4) Any specific reason for picking I-JSON ?

Absolutely. I-JSON is more likely to be interoperable than plain JSON: that's why it exists. Given that the developers of the clients for this protocol will be different than the developers of the servers, greater interoperability should be an emphasis.

> 5) The resolver information can also be provided in the server certificate itself, for example see https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-04#section-10.1 [tools.ietf.org]. The pros and cons of both approaches need to be discussed in the WG.

Agree. If that document progresses, it will certainly have an effect on the protocol proposed here.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email