[Trans] ***SPAM*** 8.956 (5) Re: ***SPAM*** 8.1 (5) Re: DNSSEC also needs CT

Nico Williams <nico@cryptonector.com> Tue, 13 May 2014 15:25 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 486BF1A00EA for <trans@ietfa.amsl.com>; Tue, 13 May 2014 08:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 8.956
X-Spam-Level: ********
X-Spam-Status: Yes, score=8.956 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, URIBL_WS_SURBL=10] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NG-5KREUqedV for <trans@ietfa.amsl.com>; Tue, 13 May 2014 08:24:59 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6C8B81A00E3 for <trans@ietf.org>; Tue, 13 May 2014 08:24:59 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost []) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 4E74454073 for <trans@ietf.org>; Tue, 13 May 2014 08:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3VwmKuwVqUrO6+TAweea oXAtHlM=; b=KOpwwUBtOBylk07DKX+Wtyp0HeVIFTn6xR7qAAeL1rKDhyNOhOax H3DoJpNJWKEQoxKMN32JC51q9vgrkCz8PIlL19iUrRbjHhO2YRtHeuZh1aQdRCfk Xd8JOxktayH0EuJ2LPB2T0l9JF2WJ/YMO9GkbzFwRhHFFU2kKPjo19I=
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id F388154075 for <trans@ietf.org>; Tue, 13 May 2014 08:24:52 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hi2so7288037wib.4 for <trans@ietf.org>; Tue, 13 May 2014 08:24:51 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id ry13mr2376227wjb.69.1399994691694; Tue, 13 May 2014 08:24:51 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 08:24:51 -0700 (PDT)
In-Reply-To: <CABrd9SRQFJqL=8HKydTkEam46JjB9=Xgfc30kDwNgdp_m8YFMg@mail.gmail.com>
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> <CABrd9ST7K-7RGwGD2G+kDcVSceC2ZJ-5Tz2tdp5NWa3cqBK+-w@mail.gmail.com> <CAOe4Ui=nqmCfjBYNE2CJtEs1jnbavpY4Dv-T3FRDdAwAA2dScg@mail.gmail.com> <CAK3OfOiYMJkXVR+QsCzEV0ir6u53coJz0b-JdGGD5bTTz5YcMg@mail.gmail.com> <CAOe4Ui=u0fkm9_nuXx_6gpH6jHM5pBvzjzru9O8y3bpLkA0qmw@mail.gmail.com> <CAK3OfOi6y=QAMXe_2axiavxwR5nS2Uv8SM4JxQHsvEKbUyNGCA@mail.gmail.com> <537231FC.4010007@fifthhorseman.net> <CABrd9SRQFJqL=8HKydTkEam46JjB9=Xgfc30kDwNgdp_m8YFMg@mail.gmail.com>
Date: Tue, 13 May 2014 10:24:51 -0500
Message-ID: <CAK3OfOi2RJQYuPmp7d28JMYPfJEPantd=HHkG_RRTmTOo7+Y_g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Ben Laurie <benl@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QS2cT1-R3uanW6CHETYGvTMVIEI
Cc: Warren Kumari <warren@kumari.net>, Paul Wouters <paul@nohats.ca>, Joseph Bonneau <jbonneau@gmail.com>, "trans@ietf.org" <trans@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: [Trans] ***SPAM*** 8.956 (5) Re: ***SPAM*** 8.1 (5) Re: 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: Tue, 13 May 2014 15:25:00 -0000

On Tue, May 13, 2014 at 9:58 AM, Ben Laurie <benl@google.com> wrote:
> On 13 May 2014 15:53, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> So if Alice registers example.co.uk, she wants to do misissuance review
>> for that zone.  But in a DNSSEC context, she needs to do misissuance
>> review of the parent zones as well.  That is, she wants to ensure that
>> .uk is not publishing spoofed records about the .co.uk nameservers and
>> zone signing keys (how does she know if a change in DNSSEC records at
>> this layer is a legitimate change?).
> I don't get why Alice would want to do this - all Alice cares is that
> example.co.uk is correctly issued, right?

To detect MITM attacks by uk. on her peers.  Of course, given
caching... it's going to be very difficult for uk. to mount a targeted
MITM attack on Alice's peers.  That's not the case with the PKI
because there's no lookup process there, so no caching.  Still, it
seems reasonable for Alice to check uk.'s log.  Besides, the cost of
doing so is marginal: in general the closer to the root in DNSSEC the
lower the log volume (what do we call this?) will be.

>> 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?)
> My naive first crack at this question was: each parent designates where its
> children are logged (which may be the same log as the parent, of course, but
> allows the parent to delegate for big/spammy users).

Right, . won't want to share a log with com., no doubt.  But that's
not an answer to Daniel's question, which is about whether Alice's
auditing job is easier or harder in the DNSSEC case compared to the
PKI case.  IMO it's easier; I explained my answer separately.