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

Nico Williams <nico@cryptonector.com> Tue, 13 May 2014 18:55 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 43F8B1A0131 for <trans@ietfa.amsl.com>; Tue, 13 May 2014 11:55:01 -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 6aZ0qP0SfWC8 for <trans@ietfa.amsl.com>; Tue, 13 May 2014 11:55:00 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4F6811A0096 for <trans@ietf.org>; Tue, 13 May 2014 11:55:00 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (localhost []) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E4B72678071 for <trans@ietf.org>; Tue, 13 May 2014 11:54: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=WPDSyot8hPr1OLMXn2ke ARp2sNU=; b=EBpkyerrUDM2z9sLuPNNXpfB/mqD2YaKisOJVzMtgbZQetLAeEqX Q3bhgoBsDOAkPDcsLEUv5AwpF0E/wtONQ1SVyr1Jkq7wvTRCLrQ9LRi9R70MGSHh 06OT6mr23Gt24ZxV9kHhTNetlT8y36ke3nYRVA7draL8yE+H1fSjPCM=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 93848678057 for <trans@ietf.org>; Tue, 13 May 2014 11:54:53 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hi2so1161557wib.1 for <trans@ietf.org>; Tue, 13 May 2014 11:54:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id xl6mr22438914wib.42.1400007292152; Tue, 13 May 2014 11:54:52 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 11:54:52 -0700 (PDT)
In-Reply-To: <53725B32.5090203@fifthhorseman.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> <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> <53725B32.5090203@fifthhorseman.net>
Date: Tue, 13 May 2014 13:54:52 -0500
Message-ID: <CAK3OfOi2511OjCLu8mMTc5VJ2UJ9paYRNWvAeyZ+Jf8DM1MR=w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/J8MzltQE67sdmMTDbIhhl8nU2oU
Cc: Warren Kumari <warren@kumari.net>, "trans@ietf.org" <trans@ietf.org>, Joseph Bonneau <jbonneau@gmail.com>, Ben Laurie <benl@google.com>, Paul Wouters <paul@nohats.ca>
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 18:55:01 -0000

[What's with the spam crap in the subject?]

On Tue, May 13, 2014 at 12:49 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On 05/13/2014 11:24 AM, Nico Williams wrote:
>>> 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".


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

Publicize the event.  That's all you can do.

Given a trusted-third-party introducer model, it isn't possible to
prevent MITM attacks.  At _best_ you can detect them.  The handling of
revealed (detected or otherwise) MITM attacks is an entirely political

> 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
> sentence").

We can't even do that.  We can only shine sunlight on CA problems.

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

No, we cannot take action beyond deploying a protocol that makes
some/most MITM attacks by TTPs evident.  Anything else is fantasy that
will shortly crash into the rocky shores of reality.

(Apologies for the strong words.)

There are two or three sub-types of political problems here.  All are
clearly out of scope for the IETF, so I won't bother listing them.
The IETF simply cannot address layer 9 problems directly.  All we can
hope to do here is to deploy measures that make it harder for MITMing
by TTPs to go undetected.  We probably can't even _directly_ cause TTP
MITM events to be publicized.