Re: [dane] [Trans] CT for DNSSEC

Wei Chuang <> Wed, 29 March 2017 14:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A69DF129474 for <>; Wed, 29 Mar 2017 07:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 1Ku8fvJWDp89 for <>; Wed, 29 Mar 2017 07:33:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E84FE12953D for <>; Wed, 29 Mar 2017 07:33:04 -0700 (PDT)
Received: by with SMTP id z204so19783372vkd.1 for <>; Wed, 29 Mar 2017 07:33:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OdU5jWePux8YPa9k+GrP/buXK2KM9V+/ybJMXtOWZHw=; b=IHmCVoQsfPWmzRphTRLgT8d7o60yTuvSpXqMB4CgRngy0+lc/L0c3oIdj2+c85j8Fw uLbRNp1CGUraIB52c/0RmqsPGe7QIcwPXc7xtH+0L7nSxNtJ+mER5LE6gXe8qCFsgknB WCh8ZJPUvpyCB0DUQeONw5K1sm1oZliXJcOVuCEy9cwP3OWi0d+LwvxN4irfYvX64uY6 mgZ049gWHWfWOD47gTXTkWnqNVH9FwgfMemi/eHc0c36JEtVd3FMn4Ltd5XGmn/OfriZ ClW5cxTEKUASHgpy4wzObl4/PT4Ol7omeKc27FPMtQ0RYJ5hjMiA3kHjl53QpgrRMEut 1/1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OdU5jWePux8YPa9k+GrP/buXK2KM9V+/ybJMXtOWZHw=; b=URrQw3E8DSr9nklEBLez6NM07JMQy1/OdaeoaXO11eRUlFsD+29B1+vXNi1Cv3bSOv /4YEiunELkD0e4jNFPaUt/u6vjMQjCqh7xUGb9ZGZixCJs2yI7p/hHYxTc0trtzWMMTA Mw9Khm2mmZwC/tfaec4HBbUnpX3adTOP6sitFejBA9gPP2t6g0WzWn90wP3WuohSJ8tr /cNTbEjp7tX3Jgk4P64v88m1mBTO5F96F01gWdVZJaIj+CAqxbpkPRbFisuNTkIYKt2w GsJx81WB1TcA0UGVSRoumttpdIy5KFYvbxR6RaYPQlFjTyT0GvfP6EVXHYrwuV8ndIPf RqAg==
X-Gm-Message-State: AFeK/H055cEDpnlbQK8QxTYuf5Q31yLEG/aCxx6XuVoqd2upyg7IYe+XXg3LJwQSEFbuDajJH1HTbgWIZePLE6+0
X-Received: by with SMTP id n17mr350521uab.178.1490797983570; Wed, 29 Mar 2017 07:33:03 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 29 Mar 2017 07:33:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Wei Chuang <>
Date: Wed, 29 Mar 2017 09:33:02 -0500
Message-ID: <>
To: Viktor Dukhovni <>
Cc:, IETF DANE Mailinglist <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045ddecc465c77054bdf7477"
Archived-At: <>
Subject: Re: [dane] [Trans] CT for DNSSEC
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Mar 2017 14:33:08 -0000

Thanks very much Viktor that explanation of NSEC(3).  Just one follow up

On Mon, Mar 20, 2017 at 6:00 PM, Viktor Dukhovni <>

> > On Mar 20, 2017, at 6:43 PM, Wei Chuang <> wrote:
> >
> >>> No, this is because the parent can spoof any data for the child.
> >>> It is unrelated to DNSSEC.
> >>
> >> With qname minimization, the parent will first need to deny an NS
> >> RRset for the child, and those DOE records are better candidates
> >> for logging than routine non-NS queries.
> >
> > Can you expand on how the the DOE record (which I assumes means
> > denial-of-existence) could work with an adversarial parent?
> Yes, DOE is denial of existence.  When the child sends NS queries
> as part of qname minimization a negative response (no NS records)
> will include signed NSEC(3) records to that effect, signed by the
> parent zone.  These are candidates for logging.

Understood now I think.

> The key question is how to avoid logging ridiculous volumes of
> data that can DoS any log service and also disclose too much.

+1 as this is logging NSEC(3) would make the logging rate proportional to
all RR churn.

Let put out an idea to attempt to mitigate this.  (And apologies ahead of
time if this is obviously wrong as I'm pretty new at DNS/DNSSEC)   For
this, the main thing this is trying to track is the existence of DS and its
DOE.  Why not create an explicit Non-existence of DS (NDS) RR that gets
logged along with DS and NS?  The effect is then is that every NS will then
have either a DS or NDS RR.   Then the rate of logging becomes proportional
to max of NS and DS changes.  I suspect NDS won't have the same enumeration
problems as the NSEC(3) since lacks next-signed link, and is paired with an
NS record anyways.  Also NDS does not change NSEC(3) behavior DOE behavior.
 (To be complete there could be a policy declaration mechanism for this but
that's details).