Re: [Trans] DNSSEC also needs CT

Phillip Hallam-Baker <> Fri, 09 May 2014 23:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66FF31A008A for <>; Fri, 9 May 2014 16:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hyw8fo3HWd5D for <>; Fri, 9 May 2014 16:12:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::230]) by (Postfix) with ESMTP id 90F651A0049 for <>; Fri, 9 May 2014 16:12:15 -0700 (PDT)
Received: by with SMTP id p9so5805982lbv.7 for <>; Fri, 09 May 2014 16:12:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MNUCYhMpfUIoIyo7oY8cTgFLGOmi1Cm628EqAXM6Pag=; b=WKhHsF2wRXaG1p+zq2E6IvyRJa/gZitNN6GXk+3SPBcNklXDtS7fhnb6BfpAEBRC/F S+PY1WvHq+ucWCajKgckL8chUOY03GR1xrtTii1PCC7Iceg1vGnjgKz0iKWLSQDWUBI1 FZjJkkXQPYsAYiOPmjMZSkS5LFlGK/0ZnLTTrlsBC9Zu8MbAfWoPN4UZyHQQ4HBA1LL6 UHF5stI8SH/iOsIVK/nbc+VvF2epj6KS1pvgNpLT0Jymh66byvhJ4E/V7pqfqPIzoYjT yls8TwaC6GrJ0bQ6hPuXuXhOcObHOTcw48oG8u+RITyNjIWl/KFMc5yXl8QEJbNJSaXV y/xQ==
MIME-Version: 1.0
X-Received: by with SMTP id lf10mr1214408lac.21.1399677129768; Fri, 09 May 2014 16:12:09 -0700 (PDT)
Received: by with HTTP; Fri, 9 May 2014 16:12:09 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 09 May 2014 19:12:09 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Nico Williams <>
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: Fri, 09 May 2014 23:12:17 -0000

There are lots of tricky problems here.

* DNSSEC assertions are time limited
* DNSSEC record signatures have to be rolled up into some sort of
container before they could be used
* TRANS assumes X.509v3 certs.

The simplest way to align things is to simply have a certificate
issued for the DNSSEC zone KSK and plop that in the log as normal.

The actual certificate could be self signed or signed by another
hierarchy. I can't see any value in making specific requirements about
the cert unless there is an ulterior motive to ram some other
technology down people's throats. Which is a really bad move for
trying to get adoption of a science lab stage technology. We did that
with PGP (and S/MIME come to think of it).

Given the Trans architecture, it probably makes most sense if someone
is signing the certificate with some sort of key because the basic
principle of Trans is that the log is holding the certificate issuer
accountable for what they sign. But rolling up self signed certs into
a trans log can also make sense.

On Fri, May 9, 2014 at 5:31 PM, Nico Williams <> wrote:
> DNSSEC is a PKI [of sorts; please, no need to pick nits about that].
> It stands to reason that DNSSEC should have similar trust problems as
> PKIX.  I believe it does indeed.
> It follows that things like CT that we're applying to PKIX should be
> applied to DNSSEC as well, where possible.
> I don't see any reason why CT couldn't be extended to DNSSEC.  IMO, it
> should be done.
> Note that DNSSEC needs CT independently of protocols like DANE, but
> any protocol that allows a DNSSEC MITM to bypass PKIX CT (as DANE
> effectively does) should increase the need for CT for DNSSEC.
> Note too that I'm not in any way saying that DANE and similar should
> block on CT for DNSSEC.
> Sincerely,
> Nico
> --
> _______________________________________________
> Trans mailing list