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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 13 May 2014 17:50 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 []) by ietfa.amsl.com (Postfix) with ESMTP id C35EC1A0187 for <trans@ietfa.amsl.com>; Tue, 13 May 2014 10:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 8.1
X-Spam-Level: ********
X-Spam-Status: Yes, score=8.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_WS_SURBL=10] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EW8XYqnUKZj3 for <trans@ietfa.amsl.com>; Tue, 13 May 2014 10:50:02 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org []) by ietfa.amsl.com (Postfix) with ESMTP id 099BD1A0126 for <trans@ietf.org>; Tue, 13 May 2014 10:50:02 -0700 (PDT)
Received: from [] (unknown []) by che.mayfirst.org (Postfix) with ESMTPSA id 6CECCF984; Tue, 13 May 2014 13:49:50 -0400 (EDT)
Message-ID: <53725B32.5090203@fifthhorseman.net>
Date: Tue, 13 May 2014 13:49:38 -0400
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: Nico Williams <nico@cryptonector.com>, Ben Laurie <benl@google.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> <CAK3OfOi2RJQYuPmp7d28JMYPfJEPantd=HHkG_RRTmTOo7+Y_g@mail.gmail.com>
In-Reply-To: <CAK3OfOi2RJQYuPmp7d28JMYPfJEPantd=HHkG_RRTmTOo7+Y_g@mail.gmail.com>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="DxvaiKsM4eKibgdEvpshBur9MPS96CFTo"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4wsIQAJBQg5EljYfOJgqqqrB6U8
Cc: Warren Kumari <warren@kumari.net>, Paul Wouters <paul@nohats.ca>, Joseph Bonneau <jbonneau@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Subject: [Trans] ***SPAM*** 8.1 (5) Re: 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 17:50:04 -0000

On 05/13/2014 11:24 AM, Nico Williams wrote:
> 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.

Yes, this is why Alice should care.   Note that "peers" means
"communication partners", and not "other registrants within the .co.uk
public registry".

> Of course, given
> caching... it's going to be very difficult for uk. to mount a targeted
> MITM attack on Alice's peers.

I'm not convinced that DNS caching is necessarily protective in the case
of an attacker who controls the network.

> That's not the case with the PKI
> because there's no lookup process there, so no caching.

There are discussions of DNSSEC information being stored and shipped in
X.509 certificate credentials, which would also bypass the DNS 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.

So what is Alice checking in .uk's log, or the root zone's log?  How
does Alice know whether a change in (for example) the delegation for
co.uk is correct/acceptable or not?

I think Alice wants to look at the following things from looking at the
logs for .uk:

 0) ensure that she knows all valid possible .co.uk delegations,
including their log info (there's a time window of concern here -- i
think she cares about it from when she first registered the domain to
the present.  if she has already reviewed up to time T, can she just
then search from T+1 to the present?  or is there some concern about

 1) for the logs of each of those delegations, she needs to review them
for the presence of delegations of example.co.uk (evidence of a
malicious zone cut), or records from within the example.co.uk zone
itself (evidence of malicious data, like glue records, which could be
served from the parent zone directly).

so in order to detect misissuance in a DNSSEC CT model, Alice would need
to review the logs of every zone above hers in the hierarchy.  does that
sound right?

> 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.

I can see the argument for it being cheaper in the DNSSEC case.

I do wonder what we can then *do* about a detected misissuance in
DNSSEC, though.

For CAs in the X.509 CT, what we can do is encourage browser vendors to
drop that CA from their trusted root store (e.g. the diginotar "death

for DNSSEC, it sounds like we'd need to threaten to drop the whole zone,
which seems unlikely.  Are there other recourses that could be taken by
an "interested party" who detects misissuance of one of their zones?