Re: [Trans] DNSSEC also needs CT

Nico Williams <> Mon, 12 May 2014 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFD241A073E for <>; Mon, 12 May 2014 10:40:48 -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 cwdMj9JFrvZT for <>; Mon, 12 May 2014 10:40:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D6A3E1A073C for <>; Mon, 12 May 2014 10:40:47 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 03EEA674059 for <>; Mon, 12 May 2014 10:40:42 -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=cXKm/je4UhHt9j5fWQrW 3Q4DUfw=; b=ZEhh2VhJVLDBJ3zTGyF+cb95xGIc5XmPU/fbYxhItQz+wHFy0E4W 6/tNfmlEg8KUECkq+yNd2qy9c69XIiC6yOExxqdXMmkENNP9MfbiEKfHGyjboZww skL93bTnFASvPE+y7TSIiP1lygrypXu5+IO0nZZOYAjUMPXCHtNxoeM=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 7A4C5674058 for <>; Mon, 12 May 2014 10:40:41 -0700 (PDT)
Received: by with SMTP id m15so7084334wgh.4 for <>; Mon, 12 May 2014 10:40:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id v1mr16586777wiw.5.1399916439809; Mon, 12 May 2014 10:40:39 -0700 (PDT)
Received: by with HTTP; Mon, 12 May 2014 10:40:39 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Mon, 12 May 2014 12:40:39 -0500
Message-ID: <>
From: Nico Williams <>
To: Joseph Bonneau <>
Content-Type: text/plain; charset="UTF-8"
Cc: Warren Kumari <>, "" <>, Paul Wouters <>, Ben Laurie <>
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, 12 May 2014 17:40:48 -0000

On Mon, May 12, 2014 at 12:22 PM, Joseph Bonneau <> wrote:
> I'm wondering what the exact threat model is here. Imagine a malicious
> domain operator wants to sign some DNSSEC records for use in an attack. They
> include hashed of them in their log, then claim to "lose" the original
> records, or issue the equivalent of SCTs and then never include them within
> the MMD. Who is checking up on them for this? Does the superdomain that

Clients (lazily perhaps).  The public.  Domain owners.  Registrars.

Remember, com. and . cannot merely MITM  com. would have
to MITM as well.  And . would have to MITM com. too.  These
would be noticeable.

> signs this domain's record has to be doing full auditing of their DNSSEC-CT
> log? Does this still work then as anti-DOS if the superdomain has to do all
> of this auditing anyways (I suppose it could be made random, but then the
> domain can try to hide malicious entries with lots and lots of spam ones).

"Loss" of log entries gets detected.  Detection of MITM attacks by .
and TLDs would result in bad PR, and the news would spread quickly,
therefore they [mostly] wouldn't do it.  That's the point of CT.

I don't understand you question about anti-DOS.

> Furthermore, is this requirement recursive? What if a malicious domain
> agrees with a subdomain to not audit their
> DNSSEC-CT log properly, so malicious records can be signed for
>, not audited by, but if com (who we assume is
> honest) only audits's log they'll think it's in valid order. Is
> there a way to prevent the root from having to audit every log everywhere?

Domains would get to opt out for privacy reasons.  If opts
out, oh well.  This isn't about auditing every zone.

> Also, the penalty for failing some audit check is losing control of your
> domain? [...]

Eh?!  Who said that??  Nobody proposed that; nobody would.

Failure to include signatures in the log -> detection -> bad for
public relations -> incentive for CAs/registrars not to MITM.