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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 07 May 2021 12:04 UTC

Return-Path: <shollenbeck@verisign.com>
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 5752A3A1EAB for <dns-privacy@ietfa.amsl.com>; Fri, 7 May 2021 05:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 mvWqjZsT2XUR for <dns-privacy@ietfa.amsl.com>; Fri, 7 May 2021 05:04:35 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 D2DD43A1F4F for <dns-privacy@ietf.org>; Fri, 7 May 2021 05:03:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5556; q=dns/txt; s=VRSN; t=1620389033; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=OkiTSimElehQBnTM9i7BEcsNKhOJFnDMPZDb7YjCV2A=; b=Vn5thIpTju06S0Ra2q6AjmvoaHU2dWJZVLKTjX9jMITcQ2LuR2LbHQU6 7KZfg2uUxBGEGtkA54itlENZi0YM+TaLcf+ptMBlLCQHZMpnCrW+F4Yl0 oPz07LKHeSEquuI2yL6PSBw+H6voML5cfrW/bhLtekToPvZjnqnAoW0jO kLq4KetcyzMaf3n+3yzFxRzPcvVQf+RSFHVeZitJkzNv7+mXVa4oAqgIC 5li1D5WJWcMiHG9qRITlYyN/0EoeYqEGTA33sXCPBZ6ki2HpfH3Qb7dla BtYfD/oXr/bYcBSysd83CHGFBmc1/wGZni5mmB8VRImCm/GpPGhaA0zfR g==;
IronPort-SDR: 2VmUbPGXrqIibuJzTXEMysD+sCb84EiZLpNQ6sGiOvPRThiCio4V+FIEevYe6b4zA9wQI1Uc6q 3e1w8EEwIP8mZiaJ1U1/oQ0ZT/BVLWFTFkirDnw5RD3TPxfujBXOxIREzQ4vu0rZw+OlTlBTUx IrMOLRag2WfWXNlXnKmEdu4lLtoGuajDU5q+U2oHLojNOPqAUYuDutpilZlD+a+HAVrE/nco/q +/Cux4Lm/U5/xEKxaIKRrhpJDl2pu0xQlOcqViKzumLDystzEY5aHojSsNgqFoc+iSSBclSyFz UZc=
IronPort-HdrOrdr: A9a23:6JvGhqu/SspMweikuwX1rd7S7skDVNV00zEX/kB9WHVpm5Sj5q STdPRy73PJYUUqKRYdcLe7SdO9qBLnhOVICOYqXYtKMDONhILsFvAG0WKA+UycJ8SdzJ8/6U 4IScEXY+EYT2IK7/oSizPWLz9U+ri6GdeT69s2oU0BceggUdAH0+4wMHfjLqRZfng/OaYE
X-IronPort-AV: E=Sophos;i="5.82,280,1613433600"; d="scan'208";a="6719040"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 7 May 2021 08:03:51 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2242.008; Fri, 7 May 2021 08:03:51 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "paul.hoffman@icann.org" <paul.hoffman@icann.org>, "bemasc=40google.com@dmarc.ietf.org" <bemasc=40google.com@dmarc.ietf.org>
CC: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted Recursive to Authoritative DNS
Thread-Index: AQHXQvAOf3KK+7cg0Uu09kCev4ZUqKrX6jVQ
Date: Fri, 7 May 2021 12:03:51 +0000
Message-ID: <15dfc77f144840bda5c946ae757862fe@verisign.com>
References: <161997426960.11261.17005541940248978884@ietfa.amsl.com> <4490d7382c7efb10bf5689f655bf890d7b76bed8.camel@powerdns.com> <CAHbrMsCAoMQe=kwaeU7w6eZNwwFT8Syc+8j7EeDgBCvMPBsFsQ@mail.gmail.com> <F1860384-B0F7-4F97-85BF-A121E969790F@icann.org>
In-Reply-To: <F1860384-B0F7-4F97-85BF-A121E969790F@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Nkg6QpLFUjr1bGYn9nRMpVfbIPQ>
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 12:04:49 -0000

> -----Original Message-----
> From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Paul
> Hoffman
> Sent: Thursday, May 6, 2021 11:21 PM
> To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
> Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
> Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Common Features for Encrypted
> Recursive to Authoritative DNS
> 
> 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://secure-web.cisco.com/15G9BV5N6Ayfy89k3tshwvv0Hj-
> zjPlc6kJw1CJqi6AgP3dFYb3rxKKH8mi4aa9YeME86836s0ekEY1nApKWIFnccrAv
> IZEd6FCFj83J5RDOpPrUmu05qr8Q9AdovzfGTj7OCaECH7_kA7XdSfC_LW1Ldh
> T68yxlKSrCBbonEKberR2w0XZ3FpPvQCuROK63spcmNV-
> n3kzVu8JE663OkGbqoSrNiKazCnaj6b6to34xrxtNvrtC5Gk2vycrcfE4S-
> IKD5bXC2IYoYt563cbwaibm-
> zEtpU_H5WIMSebB9l0/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtm
> l%2Fdraft-ietf-dnsop-svcb-https%23section-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.

[SAH] Asking the question here doesn't make this the wrong venue. If these records need to be treated like glue records, publication needs to be addressed _somewhere_. Once a preference is established, the specification work can be handed off to the appropriate WG.

Scott