IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Wed, 17 July 2019 16:17 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 1F38312068A for <dnsop@ietfa.amsl.com>; Wed, 17 Jul 2019 09:17:28 -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 IoL4QqfVYh0t for <dnsop@ietfa.amsl.com>; Wed, 17 Jul 2019 09:17:26 -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 556FB120887 for <dnsop@ietf.org>; Wed, 17 Jul 2019 09:17:26 -0700 (PDT)
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 Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Jul 2019 09:17: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.1473.005; Wed, 17 Jul 2019 09:17:24 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: tirumal reddy <kondtir@gmail.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Request for adoption: draft-sah-resolver-information
Thread-Index: AQHVPK0DoHzyuqLa+E+4u0zgDrIvlqbPcjmA
Date: Wed, 17 Jul 2019 16:17:24 +0000
Message-ID: <78FC8A42-B9E0-4785-90DF-FE7434FB4457@icann.org>
References: <F00B09EC-24D8-40C1-8A6C-86C2FD63A062@icann.org> <CAFpG3gcLF-tYJtiiV8kDKHa-rdSb=DQqLYuV-n+XX-PG5qEWmw@mail.gmail.com> <76A15C99-20BB-4AC8-9F34-D690D27B81EA@icann.org> <CAFpG3gdySm18k5jD9hthMEnzb1dPSP7tsq4N02ApcmoyP9O2rA@mail.gmail.com>
In-Reply-To: <CAFpG3gdySm18k5jD9hthMEnzb1dPSP7tsq4N02ApcmoyP9O2rA@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: <49B95BA02235224387D72F662E0B7902@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IfN8QLPuZdLogW2NcEQcdHNgKvs>
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: Wed, 17 Jul 2019 16:17:28 -0000

On Jul 17, 2019, at 7:36 AM, tirumal reddy <kondtir@gmail.com> wrote:
>> 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.
>> 
> Attackers can also host DoH servers and claim they have better security policy, How will the stub resolver know the server is not lying ?

The same way that they will authenticate any policy information. This is no different than any other policy choice, is it?

> > 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 fruit.
>> 
> Yes, but how will the client know it is communicating with an attacker's DoH server or not ?
> In other words, if the client does not securely learn the IP address or domain name of the resolver, the client could end-up retrieving the attacker's resolver information.

Are you saying that the only way for a client to learn policy information is from secure DHCP or secure RA? It seems like others here disagree with that, and want network administrators to be able to leverage the resolvers under their control to issue policy statements.

> Discussing these future configuration options without solving the secure bootstrapping problem is of little use to implementations and deployments.

Others seem to disagree with that statement.

> > 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.
>> 
> JSON also provides interoperability, please see https://tools.ietf.org/wg/jose/charters.

I-JSON was partially motivated by problems discovered in JOSE.

> My other question is why JSON and not CBOR ?

CBOR has no advantages in this use case, and JSON is easy to put into master files.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email