Re: [Trans] DNSSEC also needs CT

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sun, 11 May 2014 14:40 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE11A025D for <trans@ietfa.amsl.com>; Sun, 11 May 2014 07:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0LX7AZE9pvZ for <trans@ietfa.amsl.com>; Sun, 11 May 2014 07:40:41 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 88E5D1A0225 for <trans@ietf.org>; Sun, 11 May 2014 07:40:41 -0700 (PDT)
Received: from [192.168.1.211] (fluxo.info [201.27.11.148]) by che.mayfirst.org (Postfix) with ESMTPSA id 6657CF984; Sun, 11 May 2014 10:40:23 -0400 (EDT)
Message-ID: <536F8BC4.5070405@fifthhorseman.net>
Date: Sun, 11 May 2014 11:40:04 -0300
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>, Warren Kumari <warren@kumari.net>
References: <CAK3OfOjiL2DTJPH3CaAjg8YGrrwN56SgQ+DnqPXx4MLbgXQN+A@mail.gmail.com> <CAMm+Lwieij8Tm8V-gpE0eAfwie1dgtFL_Ga8dPkJFKJKLQDAcA@mail.gmail.com> <CAK3OfOiKjY6YyiyeHiFJrecZfj_uQ-2k+KucKnzb9Yt8VCRPOQ@mail.gmail.com> <CAHw9_iKpN7AXfrH6SzroMukrKTPR5z24U9KfWpVW-F2R_wX3ag@mail.gmail.com> <alpine.LFD.2.10.1405101722240.897@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1405101722240.897@bofh.nohats.ca>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7ICnWfun8VottXnugAD5AbbK8hn8RWAL3"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mc9I6LZ29__RvZG76GkvWFGWZEQ
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] DNSSEC also needs CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 May 2014 14:40:48 -0000

On 05/10/2014 06:31 PM, Paul Wouters wrote:
> On Sat, 10 May 2014, Warren Kumari wrote:
>> The main incentive (that I can see) to DoS the logs would be for the
>> lolz[0], and so (IMO) the protection does not need to be very strong

Do not underestimate the appeal of the lulz for some people.

> Or just say that anyone who puts in more than X amount of DNSSEC CT
> entries underneath themselves must run a public CT node themselves. So
> if nohats.ca want to get more then X entries, or one of their
> subzones/customers wants more than X entries, either they or their
> subzone/customer will have to run a fully functional CT node. And if
> the node goes down, their new entries will be refused.

This sounds expensive to verify, and still a bit unclear to me.  do you
mean that nohats.ca would need to run its own log for its own zone?  At
the moment, we're not expecting the authorities to run their own logs --
this seems like a change in semantics and control.  clients would also
need to know to switch over to another log in that case -- how would
that be done?  What kind of limits would this architecture place on
undetectable misissuance?

Or do you mean they would  would need to contribute to the CT
architecture in some other way?

Tthis question is related to the (currently idle) DBOUND discussion [0]
and (currently) the public suffix list [1].  If we can draw a line
between public registries (which need to be held publicly accountable)
and private zones (which in many cases may prefer to avoid full zone
enumerability that comes with CT) then we can just ensure that CT-style
audit logs apply only to the public registries.

Public registries themselves have some interest in limiting pollution,
and usually a revenue stream that scales with the size of the registry.
These are properties that we might be able to align with a logging
infrastructure.

So the idea is that for DNSSEC: the root zones and the TLDs (or
TLD-equivalents) would get CT-like logging, but children of those zones
(as you cross into a private administrative zone) would *not* get
CT-like logging.

I'd be curious to hear what other folks think about this balance, and
what it would take to draw that line cleanly.

	--dkg

[0] https://www.ietf.org/mailman/listinfo/dbound
[1] https://publicsuffix.org/