Re: [dns-privacy] [Ext] Common Features for Encrypted Recursive to Authoritative DNS

Paul Hoffman <paul.hoffman@icann.org> Fri, 07 May 2021 03:21 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 890883A115A; Thu, 6 May 2021 20:21:02 -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 7hNZGlaBoqBn; Thu, 6 May 2021 20:20:58 -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 340423A115E; Thu, 6 May 2021 20:20:58 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa5.dc.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 1473KuBr013766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 May 2021 03:20:56 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Thu, 6 May 2021 20:20:55 -0700
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.0858.010; Thu, 6 May 2021 20:20:55 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: DNS Privacy Working Group <dns-privacy@ietf.org>
Thread-Topic: [Ext] [dns-privacy] Common Features for Encrypted Recursive to Authoritative DNS
Thread-Index: AQHXQu/9OqqdSGtBJE6JTxLnBm7V8Q==
Date: Fri, 7 May 2021 03:20:55 +0000
Message-ID: <F1860384-B0F7-4F97-85BF-A121E969790F@icann.org>
References: <161997426960.11261.17005541940248978884@ietfa.amsl.com> <4490d7382c7efb10bf5689f655bf890d7b76bed8.camel@powerdns.com> <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.com>
In-Reply-To: <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.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=_D7BACA20-3478-4080-A0C5-99F163AB5EB4"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-06_16:2021-05-06, 2021-05-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/PR2UykbSofKSvpqtXISEzwRSJvA>
Subject: Re: [dns-privacy] [Ext] Common Features for Encrypted Recursive to Authoritative DNS
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: Fri, 07 May 2021 03:21:03 -0000

On May 3, 2021, at 2:06 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> Thanks for this draft; I think it's clear and could be a helpful introduction.
> 
> >    If the cache has no positive or negative answers for any DNS SVCB
>    record for any of a zone's authoritative servers, the resolver needs
>    to send queries for the DNS SVCB records for some or all of the
>    zone's authoritative servers.
> 
> I think it would be worth rephrasing the words "needs to" here.  To me, this sounds like a normative requirement to perform these queries, but I suspect that's not what you mean.

Good catch. In retrospect, this topic is actually not common between the two use cases, so we'll take it out of the "common" document and expect each protocol document to deal with what to do if the cache has no positive or negative answers for any DNS SVCB record for any of a zone's authoritative servers.

> >    Because some authoritative servers or middleboxes are misconfigured,
>    requests for unknown RRtypes might be ignored by them.  Resolvers
>    should be ready to deal with timeouts or other bad responses to their
>    SVCB queries.
> 
> This sounds a bit pessimistic.  Ralf Weber recently published some figures showing a ~0.03% failure rate.  For security (in the authenticated case), any mitigations here are very delicate, and I'm a bit concerned about the brief treatment here.  (The SVCB draft has an extensive discussion: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-3.1.)

This was a leftover from earlier drafts, and you are right that this is adequately covered in the SVCB draft itself. We'll remove it.

> >    DNS SVCB records act as advisory information for resolvers about the
>    encrypted protocols that are supported.  They can be thought of as
>    similar to NS records on the parent side of a zone cut: advisory
>    enough to act on, but not authoritative.  Given this, authoritative
>    servers that know the DNS SCVB records associated with NS records for
>    any child zones MAY include those DNS SCVB records in the Additional
>    section of responses to queries to a parent authoritative server.
> 
> This sounds like a restatement of the definition of "glue".  Can we simply declare that these records are "glue"?

We do not get to redefine a 30-year-old concept just because we have a new shiny thang. We tried to say "treat similar to glue", and that wording could maybe be improved.

On May 4, 2021, at 5:28 AM, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
> 
> [SAH] …and does this imply that we need to extend EPP to populate these records?

Wrong working group, Scott. :-) My personal opinion is that there are mechanisms defined by DNSOP for child-to-parent communication that would probably work much better than yet another REGEXT WG document.

--Paul Hoffman