Re: [Trans] DNSSEC also needs CT

Nico Williams <> Tue, 13 May 2014 15:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 70F741A0124 for <>; Tue, 13 May 2014 08:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KyJ7Z4uZRTPr for <>; Tue, 13 May 2014 08:12:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 74E2C1A0125 for <>; Tue, 13 May 2014 08:11:39 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 1660A2007F008 for <>; Tue, 13 May 2014 08:11:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=g48Y6LRCtThv6aMbKR++ gMsxTes=; b=ibrT3uKFllhqDJHSbxxzotzJHWMrggbnekRvGxtmIBsj9zY8LbgX H9lNg2TXWJTUFoRW6YVnhe16uBv92GMJWUn9qebls6mkqVixkxBc0/LcJqQqnOit Va5zRtF5zyyW+iqh081bzW2+7Rm4tClVV7aCvfN+CEhyxXGEySh6u8o=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BF8212007F003 for <>; Tue, 13 May 2014 08:11:32 -0700 (PDT)
Received: by with SMTP id bs8so7264616wib.3 for <>; Tue, 13 May 2014 08:11:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id hk19mr21252934wib.42.1399993891648; Tue, 13 May 2014 08:11:31 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 08:11:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 13 May 2014 10:11:31 -0500
Message-ID: <>
From: Nico Williams <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset="UTF-8"
Cc: Ben Laurie <>, "" <>, Joseph Bonneau <>, Warren Kumari <>, Paul Wouters <>
Subject: Re: [Trans] DNSSEC also needs CT
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 May 2014 15:12:20 -0000

On Tue, May 13, 2014 at 9:53 AM, Daniel Kahn Gillmor
<> wrote:
> On 05/12/2014 02:01 PM, Nico Williams wrote:
>> The ones that matter most are the TLDs and the root.  Those get so
>> many users that they will be caught MITMing, if they do.
> I think technically what we care about is the public registries, not the
> TLDs.  This was my point about the public suffix list and DBOUND: that
> we care about just as much as we care about .net.
> I know that some people use the term TLD to refer to the public
> registries instead of "top-level domains", but i think it's worthwhile
> to be precise in this discussion.

That's fair.  I do tend to think of as a TLD... for lack of a
better term (is there one?), yes.  You're quite right: if a zone is
(has) a public registrar(s) then it should be audited w/o privacy.
Whereas if it doesn't sell registrar services, then it is less
important that it log names: we can assume that names below it are
roughly in the same administrative domain as the zone itself.

>> If has lots of customers, then they'll help audit it,
>> else they might not.
> If is handing out subdomains to its customers and
> expecting them to act as different administrative sub-zones, then
> effectively *is* a public registry, and as such it needs
> to be auditable as well.  (it also needs to be considered a public
> registry for the sake of cookies and other same-origin policy things on
> the web, for example, so that can't set cookies
> that would apply to


> Who is actually doing the monitoring and auditing is a separate
> question, though.
> note that CT appears to differentiate between monitoring (RFC 6962
> section 5.3) and auditing (RFC 6962 section 5.4) in this way:
>   Auditors make sure that SCTs are cryptographically valid against an
> STH, and that one STH chains properly to another;
>   Monitors make sure that the whole log itself is cryptographically
> valid, looking at all the data.
> Neither of these activities describes the actual checks that would need
> to happen for misissuance to be detected.  As noted in section 7.2,
> "interested parties" need to think about how to monitor to ensure that
> items with their administrative domains are not logged by other parties.

I would think that domain owners are "interested parties", and/or
maybe agents they delegate to (e.g., hosting companies).  I can audit
the logs for my domain's parent zone.  But yes, this probably needs to
be covered in more detail.  (Are there FOSS implementations of

> If this is neither "Monitoring" nor "Auditing" maybe we need a name for
> this kind of activity, so we can discuss it more directly?  how about
> "misissuance review"?

It seems to fall into "monitoring" given the text of the RFC.

> How does she know what logs to look in for this misissuance review?  Is
> there a way she can do this review efficiently?  I think these questions
> are relevant for regular CT as well, but a DNSSEC-focused CT adds the
> wrinkle of delegated zones.  (maybe this isn't actually worse than X.509
> PKI with its fully-delegated intermediate CAs though?)

No, it's easier!  With the name contraint-free TLS PKI the domain
owner has to check... every root CA.  With DNSSEC, which has strict
name constraints, there's only one issuer for each zone cut.