IETF Logo Mail Archive

Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

Paul Hoffman <paul.hoffman@icann.org> Fri, 11 December 2020 00:41 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 CCDED3A1379 for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2020 16:41:37 -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 hwJv78nrqBAv for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2020 16:41:36 -0800 (PST)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.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 CFB973A07A0 for <dnsop@ietf.org>; Thu, 10 Dec 2020 16:41:36 -0800 (PST)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0BB0fZt0016800 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 00:41:35 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, 10 Dec 2020 16:41:34 -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, 10 Dec 2020 16:41:34 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Joe Abley <jabley@hopcount.ca>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
Thread-Index: AQHWzzofPhRvn9p1EEWsetz0r1t/E6nxhXmAgAAHSoCAAAMGAIAAAtcAgAAByAA=
Date: Fri, 11 Dec 2020 00:41:34 +0000
Message-ID: <9BB8435F-F416-49CF-A232-FDCE526DCDD5@icann.org>
References: <F3CB048D-F6DB-46D7-A151-E9526FA51F47@icann.org> <A8AECB8C-E6D4-4360-A85F-2525BF001435@hopcount.ca>
In-Reply-To: <A8AECB8C-E6D4-4360-A85F-2525BF001435@hopcount.ca>
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=_A26C7B1F-516D-4F01-B4CF-487CD127C841"; 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=2020-12-10_11:2020-12-09, 2020-12-10 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_gO3VAsZaeRMKeEL179Bdu4d0dM>
Subject: Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
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: Fri, 11 Dec 2020 00:41:38 -0000

On Dec 10, 2020, at 4:35 PM, Joe Abley <jabley@hopcount.ca> wrote:
> 
> On Dec 10, 2020, at 19:25, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
>> In DPRIVE, there is a desire to TLSA records to authenticate authoritative servers. In order to do that without getting into a chicken-and-egg loop, the parent needs to authenticate the NS records of the child authoritative server.
> 
> I haven't been following dprive recently. Is there a particular document that expresses the problem statement above in more detail?

No. As you know, DPRIVE is not strong on use case documents...

> "Authenticate authoritative servers" is a bit vague for me. Parent and child are namespace concepts and not relying parties that you'd ordinarily expect to be able to authenticate anything.

A resolver asks a parent what the NS records are for the child. Today, an on-path attacker can change the answer and the resolver would not be the wiser, so the resolvers cannot trust such answers to do things like look up TLSA records. There is a desire for resolvers to be sure that what the child NS records they receive from the parent is what the parent has in its zone for the child so they can use this information to ask for TLSA records.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email