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

Brian Dickson <> Fri, 11 December 2020 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4B713A1382 for <>; Thu, 10 Dec 2020 17:21:21 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u8fQqphQulsb for <>; Thu, 10 Dec 2020 17:21:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC4443A1347 for <>; Thu, 10 Dec 2020 17:21:19 -0800 (PST)
Received: by with SMTP id u7so3949852vsg.11 for <>; Thu, 10 Dec 2020 17:21:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=opqkKmDcTqHk5qQJm8AfhJBxppFthmSfkhlNHBpusiM=; b=thhGdrxW6rw7S2rFOYn34UwHgRGl76oybu6ZSn7taouVsxwFLCIalUYToqsq0LocwR jGYWEZix21/p93sIUwMeOTxIL6iaKt8FzK4JOa0vZ8B7ykqjVfgdcHYKrl0Ykp7a/dpn Sbv6PDnjhVuR6zsZaaKmasKSmkALdLd9GrSK9T3W05Ly4cr6v+8zV2PYp8yw0hNcXph7 1OwIFwHvO+XhQ3kBokP6Vp6iBLPTaF7LqiA4GOjQlVN5lhtkf1BK4xiVec7ZLg1Ps/Ja /AxLNhEbF7mizP/WI2qE2HiHwRwQ0lh9kI3xyNrqs/xnLDFR/k7OzM8Yqsep0DDQhAUV 2CRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=opqkKmDcTqHk5qQJm8AfhJBxppFthmSfkhlNHBpusiM=; b=Uq+s9LP/DiEk547ReDCtw3b5zWbgzcabSpPK2CP+CKwx5Cf74g+oJRUhMGO4UxumfA 24TwWhb1c3dVQTrWzs3u6YkBMuXWsaw5DeOkMAPQ0OO527chSdCbOATemWW/pm+upVRN g+5aFMkKnLvbIq5rW7362lxA1FRjq4IpeyPRqLTF6h+fg+Hr54k9cDcXN1Teixw7vaZr gPY+pREZFblUF5uQeLlYE2TiGkzmX3rPfsKTKJqG9WZmEUgln3L23W8w5MxFPbmMHJ1k 4C+U0mBV0EAv4+T5RUvf/tY1kzbF1WptYqFqJCkVLgs7kWNQhvMjCS9x+GM9KyMXHri6 NZuA==
X-Gm-Message-State: AOAM533Rlcy+JskHxhFfW0lZHsb3sw3XrJPN++l5PeV0T/ek32mocZFb 2OQkADX3ilLt7IRCdCL0LeqUI5UciKr/owhODEc=
X-Google-Smtp-Source: ABdhPJwfseW33VQqs1keE8FHy7/w7zop+TNeiJVbvjHGWCV39/1AOhsmIT7uoeeQNLQ8OZEbZEBLMt2UvtaZ/9BYoVo=
X-Received: by 2002:a67:7742:: with SMTP id s63mr10926631vsc.49.1607649678770; Thu, 10 Dec 2020 17:21:18 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 10 Dec 2020 17:21:07 -0800
Message-ID: <>
To: Joe Abley <>
Cc: Paul Hoffman <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000006c74905b6261c68"
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:21:22 -0000

On Thu, 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.
> 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.
> Joe
> _______________________________________________
> DNSOP mailing list