IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Mon, 21 September 2020 15:28 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 706FF3A0770 for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2020 08:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qe2VcLLs6UjO for <dnsop@ietfa.amsl.com>; Mon, 21 Sep 2020 08:28:52 -0700 (PDT)
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 286353A0544 for <dnsop@ietf.org>; Mon, 21 Sep 2020 08:28:52 -0700 (PDT)
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 08LFSm3u024473 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Sep 2020 15:28:48 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; Mon, 21 Sep 2020 08:28:47 -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; Mon, 21 Sep 2020 08:28:47 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Tony Finch <dot@dotat.at>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Authoritative servers announcing capabilities
Thread-Index: AQHWiKvEkTwEuqKA9Uy2/6v0BBnHSalkvDIAgA34MICAAQdpAA==
Date: Mon, 21 Sep 2020 15:28:47 +0000
Message-ID: <421B7DF6-7BFE-45A8-B78A-B0860485368F@icann.org>
References: <676DE8DE-DA20-4162-B81C-C358DC7084E7@icann.org> <294f8ab0-285b-d5f2-705f-5db8c0da584d@uniregistry.com> <2B4B3FF6-44D4-4F08-81D2-718FD33A7CF0@isc.org> <92CA6178-FE2D-407E-97FB-A9E44E2647C7@icann.org> <rjhbfc$2ghk$1@gal.iecc.com> <A9FAB272-BDF6-4584-8175-0DD3D561AEB2@icann.org> <alpine.DEB.2.20.2009210045070.12960@grey.csi.cam.ac.uk>
In-Reply-To: <alpine.DEB.2.20.2009210045070.12960@grey.csi.cam.ac.uk>
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=_B6D37787-822E-4287-AE8C-77FC9464FBD1"; 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-21_05:2020-09-21, 2020-09-21 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/u2AhxWS5i7ZT5r0D5H4EGLeMpIM>
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: Mon, 21 Sep 2020 15:28:54 -0000

On Sep 20, 2020, at 4:45 PM, Tony Finch <dot@dotat.at> wrote:
> 
> Paul Hoffman <paul.hoffman@icann.org> wrote:
>> 
>> At this point, the only information we defined in the draft is for doing client subnet.
> 
> Why can't you just send client-subnet in a request and look at the answer?

That assumes that an attacker in the middle has not removed the answer. The indicator that we used as an initial idea for the capability would be signed, meaning that the resolver would expect a client subnet response and could act if it didn't get one. This is one of the reasons we chose using an RRtype over using EDNS0 for the capabilities (also: it is cacheable). Others seem to not want those features for capabilities.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email