IETF Logo Mail Archive

Re: [DNSOP] [Ext] Authoritative servers announcing capabilities

Paul Hoffman <paul.hoffman@icann.org> Sat, 12 September 2020 02:25 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 BE2EE3A0A80 for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 19:25:08 -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=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 t0orpdSqiCRj for <dnsop@ietfa.amsl.com>; Fri, 11 Sep 2020 19:25:06 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.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 D474C3A0AA9 for <dnsop@ietf.org>; Fri, 11 Sep 2020 19:24:31 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08C2OSAS027840 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Sep 2020 02:24:29 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.659.4; Fri, 11 Sep 2020 19:24:27 -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.0659.006; Fri, 11 Sep 2020 19:24:27 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Robert Edmonds <edmonds@mycre.ws>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] Authoritative servers announcing capabilities
Thread-Index: AQHWiKvWdSoNo0mpdUWCaPVJdHGE9w==
Date: Sat, 12 Sep 2020 02:24:27 +0000
Message-ID: <6F8BE5E4-F44E-42F3-AA55-8211D18956D2@icann.org>
References: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org> <20200912012935.GA703318@mycre.ws>
In-Reply-To: <20200912012935.GA703318@mycre.ws>
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=_3C37B0BD-889B-41DC-8170-236CE4207EA5"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-11_12:2020-09-10, 2020-09-11 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nsoXCmjHtwij3B3QG-e_L-2YaZI>
Subject: Re: [DNSOP] [Ext] Authoritative servers announcing capabilities
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: Sat, 12 Sep 2020 02:25:09 -0000

On Sep 11, 2020, at 6:29 PM, Robert Edmonds <edmonds@mycre.ws> wrote:
> 
> Paul Hoffman wrote:
>> The responses will be signed if the zone for which the server is authoritative is signed, meaning that validating resolvers can get authenticated information about the server if that would influence how they treat responses from the server.
> 
> How does the zone signer know the capabilities of the nameservers that
> will serve the zone and what does it do if the capabilities of those
> servers differ?

Because the zone owner wrote an AUTHINFO RR into the zone. This is no different than any other record.

> It sounds like this is incompatible with offline
> signing.

Not at all. Offline signing works on RRs.

> Must a primary nameserver exclude AUTHINFO RR's from outgoing AXFRs to
> secondary nameservers?

No.

> Must secondary nameservers fail, filter, or
> replace an incoming AXFR if it contains an AUTHINFO RR?

No.

> By making this
> an RR it seems like it would be easy to inadvertently serve an incorrect
> AUTHINFO RR.

In what case would a secondary have different information than the primary?

> I think this should be an EDNS option rather than an RR and if integrity
> protection beyond that of plain DNS is needed, it can be combined with
> COOKIE, SIG(0), TSIG, DoT, etc.

Again, we're fine with using an EDNS option if people don't want the information signed or cached. This seems like a steep limitation for benefits I still don't see (as shown above), but if that's what the WG wants, it's an easy change to make.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email