Re: [therightkey] [dane] DANE and CT

Paul Hoffman <> Thu, 15 November 2012 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 842FA21F857C; Thu, 15 Nov 2012 07:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Op16P9xGt52T; Thu, 15 Nov 2012 07:46:44 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id E25E721F8573; Thu, 15 Nov 2012 07:46:43 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id qAFFke8E064981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 08:46:41 -0700 (MST) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Thu, 15 Nov 2012 07:46:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Shumon Huque <>
X-Mailer: Apple Mail (2.1499)
Cc:, Ben Laurie <>, IETF DANE WG list <>
Subject: Re: [therightkey] [dane] DANE and CT
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Nov 2012 15:46:44 -0000

On Nov 14, 2012, at 10:14 AM, Shumon Huque <> wrote:

> For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC 
> authentication chain, not the existence of a fraudulently issued 
> certificate on some attacker's server.
> If the DNSSEC chain is intact, then presumably DANE aware clients 
> will properly authenticate the TLSA record before accepting the server 
> certificate. I admit that's a mighty presumption today, but we'll see ...

This is an excellent summary of the scenario.

However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record.

For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B.

--Paul Hoffman