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

Paul Hoffman <> Fri, 11 December 2020 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 197593A13B2 for <>; Thu, 10 Dec 2020 17:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9XTK-1RJIGQc for <>; Thu, 10 Dec 2020 17:49:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D4303A13B1 for <>; Thu, 10 Dec 2020 17:49:06 -0800 (PST)
Received: from ( []) by ( with ESMTPS id 0BB1n24V008991 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 01:49:02 GMT
Received: from ( by ( 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 17:49:01 -0800
Received: from ([]) by ([]) with mapi id 15.02.0721.006; Thu, 10 Dec 2020 17:49:01 -0800
From: Paul Hoffman <>
To: Joe Abley <>
CC: dnsop <>
Thread-Topic: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
Thread-Index: AQHWzzofPhRvn9p1EEWsetz0r1t/E6nxhXmAgAAHSoCAAAMGAIAAAtcAgAAByACAAAL8gIAAD9sA
Date: Fri, 11 Dec 2020 01:49:00 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_0A3C6427-BF7E-4377-84EA-B9F3AD5FFC65"; 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: <>
Subject: Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Dec 2020 01:49:08 -0000

On Dec 10, 2020, at 4:52 PM, Joe Abley <> wrote:
> On 10 Dec 2020, at 19:41, Paul Hoffman <> wrote:
>>> "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.

> Did I read that back correctly?

Somewhat, but not completely.

> The problems that DNSSEC is trying to solve are with identifying inauthentic data ultimately requested by applications. If an intermediate referral response includes an inauthentic NS RRSet with no RRSIGs

or an NS RRset with bogus RRSIGs

> it cannot be identified as inauthentic, but it doesn't really matter because any data that is expected to be signed from the inauthentic servers will fail validation and the application will be protected.
> The problems that dprive is trying to solve concern surveillance opportunities and information leakage. that if an imtermediate referral response includes an inauthentic NS RRSet with no RRSIGs it could cause queries on behalf of an application to be harvested by an untrusted third party at one of those inauthentic servers, which could represent a surveillance opportunity.

That is true so far, but some folks have informally gotten excited about authenticating intermediate referral responses for other reasons. (They can speak for themselves; that's not my use case yet.)

> The proposal is hence to provide a way for an intermediate referral response that includes an inauthentic NS RRSet to be identified as inauthentic so that subsequent queries to the untrusted third party servers can be suppressed.

Again, this is true so far, but others have hinted that they might use the authentication for more.

> I've now typed "inauthentic" enough that I am starting to doubt that it is a word, but "bogus" has a particular and different meaning in DNSSEC so I was trying to avoid it.

You even skipped using "bogus" once above. :-)

--Paul Hoffman