Re: [dns-privacy] [Ext] draft-pp-recursive-authoritative-opportunistic-04

Paul Hoffman <paul.hoffman@icann.org> Thu, 14 January 2021 18:12 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491A33A1514 for <dns-privacy@ietfa.amsl.com>; Thu, 14 Jan 2021 10:12:21 -0800 (PST)
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=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 vmIC8q9TeEl1 for <dns-privacy@ietfa.amsl.com>; Thu, 14 Jan 2021 10:12:20 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (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 63C9B3A150C for <dprive@ietf.org>; Thu, 14 Jan 2021 10:12:20 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 10EICJrA014427 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dprive@ietf.org>; Thu, 14 Jan 2021 18:12:19 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Thu, 14 Jan 2021 10:12:18 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.006; Thu, 14 Jan 2021 10:12:18 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: [Ext] [dns-privacy] draft-pp-recursive-authoritative-opportunistic-04
Thread-Index: AQHW6pKwb18orQ6OJkesH0qyD3xrPaon8o0A
Date: Thu, 14 Jan 2021 18:12:18 +0000
Message-ID: <982C69A3-E9D4-4FF6-9F2F-66CB279707C2@icann.org>
References: <DD73EF4B-1570-405F-A6A0-923E766925DE@cable.comcast.com>
In-Reply-To: <DD73EF4B-1570-405F-A6A0-923E766925DE@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_76F266E8-0BB4-4166-B8CB-27CFEA37F35F"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-14_06:2021-01-14, 2021-01-14 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/QD58SJYpWhIiTRHSntaCTX0qT7g>
Subject: Re: [dns-privacy] [Ext] draft-pp-recursive-authoritative-opportunistic-04
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2021 18:12:21 -0000

On Jan 14, 2021, at 8:31 AM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:

> Comments -- which may have been discussed in the WG before, in which case ignore them:

I'd rather not ignore anything!

> - The discovery method seems to be that you look at the NS RR IP address and attempt DoT on port 853. But the requirements doc draft-ietf-dprive-phase2-requirements-02 in requirement 7 suggests that instead of this that they auth SLD admin would specify secure transport preferences. Presumably this would be in some DNS RR in the SLD. Your proposed discovery method and what is suggested in the requirements doc seem to be at odds.

This was discussed at IETF 109, and I thought that the outcome was that, for opportunistic encryption, probing works fine and will inherently lead to more encryption of traffic than requiring changes to naming for servers or adding new record types. This was also discussed on the list in reply to Tony Finch's message before IETF 109 (but that never became a draft).

> - Why suggest attempting to contact via an IP rather than a FQDN in the URI? I know sometimes managing the TLS certs based on IPs rather than FQDNs can be problematic in some deployments.

I don't understand this. After all, one *always* contacts a server based on its IP address, based on doing a lookup for the domain name in the NS record. Also, there is no URI here.

We talked about using IP addresses in certificates being problematic, but so is listing hundreds of names for name servers that have vanity names for each of the names for which it is authoritative. For this draft, it truly doesn't matter what identifier is in the certificate, but the draft is still trying to work with whatever different draft that might eventually come out describing the fully-authenticated use case.

> - Is it necessary to specify the transport cache? If it helps with performance everyone will do it. And the section other than saying there MUST be a cache does not specify anything else.

In earlier discussions, there were questions about what would and would not be in the transport case, so describing the contours seemed more appropriate. If the WG wants to remove it, that's easy.

--Paul Hoffman