Re: [Trans] DNSSEC also needs CT

Nico Williams <> Mon, 02 June 2014 23:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1414A1A00C9 for <>; Mon, 2 Jun 2014 16:14:58 -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 hCr8CQSL7i0s for <>; Mon, 2 Jun 2014 16:14:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A5361A00AF for <>; Mon, 2 Jun 2014 16:14:57 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 9B016202022 for <>; Mon, 2 Jun 2014 16:14:51 -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=xveepVevWQ5fIDkXpd8G B6DB2fk=; b=aD/HFQ5A7hPkf3ZJWsbzIFR7rKIELCjb6KA1DX7HWlq1UOW3i4Hx S+45/y32hs83aKbYK+lU9eh1HHjx1kijVkLO2pm+oQdR68Fqy3IG81sd65nUZ6jk 3LQRqEuG1ZEklVJdNfze8tT1g1QqduIDa33a7fNMzQ8OVOyqZTsch8k=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 48BCB202018 for <>; Mon, 2 Jun 2014 16:14:51 -0700 (PDT)
Received: by with SMTP id m15so5787047wgh.4 for <>; Mon, 02 Jun 2014 16:14:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id y7mr26714882wib.39.1401750890056; Mon, 02 Jun 2014 16:14:50 -0700 (PDT)
Received: by with HTTP; Mon, 2 Jun 2014 16:14:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 02 Jun 2014 18:14:49 -0500
Message-ID: <>
From: Nico Williams <>
To: Stephen Kent <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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: Mon, 02 Jun 2014 23:14:58 -0000

On Mon, Jun 2, 2014 at 12:20 PM, Stephen Kent <> wrote:
>> On Thu, May 22, 2014 at 1:48 PM, Stephen Kent <> wrote:
>> I take it you concede that lack of name constraints isn't the only
>> reason to want CT.
> agreed.
>> I'll concede that CT for DNSSEC might not be a good idea.  Did I ever
>> say it is?  I started the discussion with an inference: CT is for
>> PKIs, DNSSEC is a PKI, therefore CT fits DNSSEC, discuss.
> I thought you did. I think CT for the Web PKI needs is missing an arch
> doc, and absent that doc it's now clear how good CT is for that case.
> This I consider it premature to suggest CT for DNSSEC si an obvious next
> step,
> as some have suggested.

I posted today providing my take as to one aspect of the CT architecture:

As I've understood it CT is partly about CA reputation.  As such CA
failures [to not MITM] should be handled asynchronously.  I think this
is an important consideration because it speaks to when the client
(and domain owners, and auditors) should do the hard work of checking
the CT logs.

> The experimental RFC does not provide a comprehensive problem statement,
> a clear description of all of the elements of a proposed solution, an
> explicit discussion of all of the assumptions that appear to underlie the
> design, i.e., what must happen for CT achieve its goals, and an
> analysis of what happens if some (implicit) assumptions are not satisfied.
> I'm going to develop what I see as the missing arch doc, to elicit feedback
> from
> the WG and the RFC authors. The WG can decide whether this is necessary, but
> I
> believe the exercise will, in any case, be useful.

I agree that CT is missing this.  That doesn't (and shouldn't) keep
one from asking if CT is applicable to DNSSEC, and if so what that
might look like.

Hand-waving a bit, if a) CT is a keep-CAs-honest mechanism in addition
to enabling domain owners to find out about erroneous certificate
issuance for their domains, b) CT applies to PKI in general (not just
PKI as in RFC5280), and c) DNSSEC is a PKI, then d) it's a fair
inference that CT ought to apply to DNSSEC.  The three conditions seem
to be true.

It's not a fair inference that CT ought to be applied to DNSSEC, of
course.  Even if CT can be applied to DNSSEC and even if it is
desirable to do so for many, there are still possibly strong arguments
to make against it.  For example, domain owners might object to yet
another "tax" on them: there's domain registrar fees, CA fees, and now
log fees paid indirectly.  And then auditing costs (probably
outsourced).  I'm sympathetic to such an argument.

Add to that a proper the benefit side of a proper cost/benefit
analysis...  For the TLS PKI case the benefit is:

 - mitigates the lack of name constraints
 - detects MITMing CAs

For DNSSEC the only benefit is the MITM detection one.  Assuming that
detections will be of a) errors by registrars, and b) political/legal
actions that we can't do much more about than detect...  is this
enough value to justify the additional costs?  This is a value
judgement to be made by the market.