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

Joe Abley <> Fri, 11 December 2020 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD5D43A137D for <>; Thu, 10 Dec 2020 16:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0KuJEYtTzn5H for <>; Thu, 10 Dec 2020 16:52:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C17E3A1376 for <>; Thu, 10 Dec 2020 16:52:19 -0800 (PST)
Received: by with SMTP id y15so5312032qtv.5 for <>; Thu, 10 Dec 2020 16:52:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VH33bHXPQZP2Bsk24gHLPT/rpOqYOMpMLUPdvZU5V8E=; b=T7v/ipRQomGHG4WbCFXDuKR79jYimgixabSXIMEqkUbeFDMW75TzCHqVnGzcQXc4lz js16eGZJfRU67uxCq6nEODWjdtaG2hPS1mB3q+0R8cTTkKgo4T9YwwaKPaMZ77VtN6WX 3+tSw92dvVRyjVD7UwDsk+xqUKmA2X9Df3S04=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VH33bHXPQZP2Bsk24gHLPT/rpOqYOMpMLUPdvZU5V8E=; b=UJGg4QSgJ3yuQvWHxnFGhDo2I9LDMFgH0vSyNtd6n/FZasQeQxaNdridP4qNlpuKhB Y/IlNzqR0w9601YK++QOgFuzU0+/1wMxn+bXXevoIbyYur22uEQ45AGNOAa3At/Z/Hpl 9of0cnHdPlI9o/QOFWQGm3pCSDsj0OSUgghh7dNS69EVqA5BXgjzL5eN7bMLX5LlMko0 J1RW351gDZGhzLqDT/47uOyQPzn63GBvlhcPuN6x6ayFuej0iG/ZYKkaucm5x8gqzzth 6toEqNmuoWj17YezaEO+9wygQuci5jVnsq2mz/QU561g3sWADCEWJOoRKLoUpmNCVwPP uIfg==
X-Gm-Message-State: AOAM532OKtNDO5d5ktRvsxcZ7VcKfkWyyonn/Z9GyPBZ7WmAQ5N80mdP Cg+NU+5dDqnC3fAveShqYSkETw==
X-Google-Smtp-Source: ABdhPJzjQKHhAqPrP3MIf3un0ECtpEyCjCXW+S+MaNIzZBELBAEJBscTZT6FKgCQeB2fMoP/Kza9Bg==
X-Received: by 2002:ac8:6c36:: with SMTP id k22mr12865744qtu.62.1607647938359; Thu, 10 Dec 2020 16:52:18 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:81ff:fafd:88c5:5fdf? ([2607:f2c0:e784:c7:81ff:fafd:88c5:5fdf]) by with ESMTPSA id p58sm5411255qte.38.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2020 16:52:17 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joe Abley <>
In-Reply-To: <>
Date: Thu, 10 Dec 2020 19:52:15 -0500
Cc: dnsop <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.3654.
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 00:52:21 -0000

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.

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 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.

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.

Did I read that back correctly?

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.