Re: [dane] [Trans] CT for DNSSEC

Paul Wouters <> Mon, 03 April 2017 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE6A1129515; Mon, 3 Apr 2017 12:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 14c1DmycaWMb; Mon, 3 Apr 2017 12:45:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA1801294C3; Mon, 3 Apr 2017 12:45:06 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3vxjHg4cHRzCvC; Mon, 3 Apr 2017 21:45:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1491248703; bh=Tu0tHCk+qnP2VLTZep4I6cCNKs67wfa2G2aUOAXXkCM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HYj5CKjhcn/KnfPX6LoYq9SvyRivwYTBJgWk1q/xICsINN8FXkzBe0IN5tRtngRu9 FTB0J+24Jv8adHk3EEHOu6fUU2G+ueqkTxzwRHciTG4Bs+xkT1T+HluctT5mQinR3X 5XULvi+f4Th/3thU8s9ZBBONVDBGSEu9TuPoHwu4=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Me1BQHzcV7ZS; Mon, 3 Apr 2017 21:45:01 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 3 Apr 2017 21:45:00 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 852C73943A4; Mon, 3 Apr 2017 15:44:59 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 852C73943A4
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60EC74000880; Mon, 3 Apr 2017 15:44:59 -0400 (EDT)
Date: Mon, 3 Apr 2017 15:44:59 -0400 (EDT)
From: Paul Wouters <>
To: Viktor Dukhovni <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
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: Mon, 03 Apr 2017 19:45:09 -0000

On Wed, 29 Mar 2017, Viktor Dukhovni wrote:

>> Why not create an explicit Non-existence of DS (NDS) RR that gets logged along with DS and NS?
> This is not needed, the NSEC/NSEC3 RRs already serve that role.
> For NSEC records (RFC4034), an unsigned delegation looks like:
> this proves that NS (or other depending on the content of the type
> bitmap of the NSEC record) records exist for, but DS
> records do not.

I don't think so? Because this is the parental NS RRset for the child,
which the parent does not sign. The NSEC only covers the existance of
the DS record, not of the glue records. And those glue records can
still be maliciously pointing elsewhere. Or the zone cut can be
temporarilly removed at the parent to sign the child's TLSA record

You really need to find the NSEC(3) record that proves the parent has
no DS record for the child zone, and really have to find and submit
the TLSA record and RRSIG. That way the logs can tell who signed the
DS and/or TLSA record.

Checking the child APEX is of no use because the parent might be
overriding the delegation briefly. Eg remove the DS record and/or
NS records, publish a childzone TLSA record as "without a zone cut",
and then restoring the DS/NS chain again.

The only way out I see is to log the TLSA records, so you know which
key signed it. If this is done, we clearly need a ratelimit and/or
some method of finding conflicting overlapping-in-time records.

> With NSEC3 (rfc5155), and the "opt-out" bit the situation can be
> more complex because the answer may not establish the existence of
>  Instead we may get an existence proof for the closest
> encloser (ancestor domain) and proof that "" is not signed,
> but no proof of its existence.  This means that to avoid spam, a log
> might want to independently verify the existence of the insecure
> delegation by repeating the query, so as to avoid storing data for
> non-existent domains with the insecure NXDOMAIN modified to NOERROR
> with made up NS records.

Repeating the query is not a real solution, as the malicious parent
could open a small time window for the attack and close it again.
Clients really need to submit state their validation reached. This
cannot include any unsigned state as that cannot be trusted itself,
but should include the signatures proving the unsigned state.