Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted

Paul Hoffman <paul.hoffman@icann.org> Fri, 24 April 2020 18:39 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EE33A0860 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 11:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 shXmQZKLcEC4 for <add@ietfa.amsl.com>; Fri, 24 Apr 2020 11:39:34 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 363E83A0861 for <add@ietf.org>; Fri, 24 Apr 2020 11:39:24 -0700 (PDT)
Received: from PFE112-CA-2.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 03OIdKo6030688 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 18:39:21 GMT
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.1497.2; Fri, 24 Apr 2020 11:39:18 -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.1497.006; Fri, 24 Apr 2020 11:39:18 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: ADD Mailing list <add@ietf.org>
Thread-Topic: [Ext] [Add] Drafts on upgrading stub-to-resolver communication to encrypted
Thread-Index: AQHWGmeppMeNpmlQsEy+0Y8tvSTcyA==
Date: Fri, 24 Apr 2020 18:39:18 +0000
Message-ID: <57727489-B6E3-40A4-9E72-79EB78AC671C@icann.org>
References: <E1091705-3E44-4284-AFE3-824052FBF5C2@icann.org> <CAHbrMsCdch3XN9r0t1kNGPtQv3ctXBH49QOJOsktHth-2WNEfQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCdch3XN9r0t1kNGPtQv3ctXBH49QOJOsktHth-2WNEfQ@mail.gmail.com>
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]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_E69B0AD6-B418-4F7F-B2FF-B41EB454D19E"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-24_09:2020-04-24, 2020-04-24 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/b2MnWGObQcDp4qxOKraHBhAKkz0>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2020 18:39:43 -0000

On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> Thanks for the updated drafts.  I think RESINFO is the most promising path for resolver upgrade, and I'd like to see it implemented.
> 
> The one major change I suggest is to remove the entire HTTPS mechanism from the RESINFO draft.  This mechanism creates a great deal of complexity, doesn't follow good practices for HTTPS, and doesn't obviously enable any additional use cases.  Having multiple competing mechanisms also makes interoperability less likely.

The additional use case that was brought up in earlier work is that a stub that wants to do DoH.
- It does not need to know how to make requests for a new DNS RRtype
- It can use HTTPS as it knows it
- It can get a response that can be authenticated

I understand the desire not to allow unauthenticated HTTPS because of best practices. We can remove that from the draft, but then implementers will likely go ahead and implement it anyway but without guidance about the results. Note that we are only talking about unauthenticated HTTPS *for this one use*, not in general.

> If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could always be added in a later draft.

Some people said it was insufficient because of inability to authenticate.

--Paul Hoffman