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

Ben Laurie <benl@google.com> Tue, 13 May 2014 14:59 UTC

Return-Path: <benl@google.com>
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 91CDF1A00DC for <trans@ietfa.amsl.com>; Tue, 13 May 2014 07:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 7.971
X-Spam-Level: *******
X-Spam-Status: Yes, score=7.971 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, URIBL_WS_SURBL=10] autolearn=no
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 QyIFn0tWyvMx for <trans@ietfa.amsl.com>; Tue, 13 May 2014 07:58:58 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E6F801A00D7 for <trans@ietf.org>; Tue, 13 May 2014 07:58:57 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id hq16so608291vcb.23 for <trans@ietf.org>; Tue, 13 May 2014 07:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hl/T29hTAlZJN7aNIsINsNK+xleMwLYjhWPjTfrJ3L4=; b=DSePdPVfdL8flQmkisiw/Tae18QKPWq553o9DLW6RSBgcy4DW6whQYfhNsBFy/venU cg0HJKOIdd+tYNVaJWRllM8bqYav8du6xb7ueYCNfeC9aQzH2fSqH3X7vIby26MVcIOu SSk2D/R6MivtS43MSIlmZLTvjJ3izFUw1+xZ58m31nkRtt9sgmw4LteOuJUeYr/o6cga HRZwPJA5HvncUq/KkG+VAAq+sXlzsnkiocMDw2JDpnL7BGovHJy0wHey6OKcdJbrcwhk 7cqPHpMxM+t+0IAESt3FIXVqPjR+pMrxs0STRqg4B4UtXdt4Kc9Y/r7hxi+9RC/kAroK EY7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hl/T29hTAlZJN7aNIsINsNK+xleMwLYjhWPjTfrJ3L4=; b=BaGvEqS4uVPgOELJT9tjMc06/9aMOEBqgBVN7CIRYtZodGPvR8pDP0U2xzSpj1yuDb 5GDhr83tNcU1WBqVRDXe59DxsIZpu8W2MKnYU4Qa7KMBN9lt5BeA9Et0QgpIS+Wl985A gNHHnOQDb14beVDWtKnz6SQxHKJwqFZjCSOvH0jAd+irBnb94lGd/upaHZGAVYQq+Zw7 U1eWuTbavO7k2b7+4CfFu3Zm26/co2Td/RSvHtSptCAivW8i1Bfys7wMWBfAe4pXcpy7 s9Zh3iig6KKcQX50tQaqs6ze/7Frhh4pLXSYJwG/WtZyhp88RpRtsZ9adeuJSO8utprq M2hw==
X-Gm-Message-State: ALoCoQneuDbp4ighnGEgWccS/GpckiItDI/EwXzDvJkSe6r4MzUowWHJDLq3Ttt9HKvg0VBHZUDS
MIME-Version: 1.0
X-Received: by 10.220.251.13 with SMTP id mq13mr544621vcb.73.1399993131395; Tue, 13 May 2014 07:58:51 -0700 (PDT)
Received: by 10.52.252.97 with HTTP; Tue, 13 May 2014 07:58:51 -0700 (PDT)
In-Reply-To: <537231FC.4010007@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>
Date: Tue, 13 May 2014 15:58:51 +0100
Message-ID: <CABrd9SRQFJqL=8HKydTkEam46JjB9=Xgfc30kDwNgdp_m8YFMg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: multipart/alternative; boundary=089e013cbf8a49041f04f9494d09
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EPhaZgy79l13p3X0HaXW_5YzkGc
Cc: Warren Kumari <warren@kumari.net>, Nico Williams <nico@cryptonector.com>, Joseph Bonneau <jbonneau@gmail.com>, "trans@ietf.org" <trans@ietf.org>, Paul Wouters <paul@nohats.ca>
Subject: [Trans] ***SPAM*** 7.971 (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 14:59:00 -0000

On 13 May 2014 15:53, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

> On 05/12/2014 02:01 PM, Nico Williams wrote:
> > On Mon, May 12, 2014 at 12:54 PM, Joseph Bonneau <jbonneau@gmail.com>
> wrote:
> >>> Clients (lazily perhaps).  The public.  Domain owners.  Registrars.
> >>
> >> Certainly possible, but I wonder how much this will happen in a world of
> >> thousands of DNSSEC-CT logs existing for various domains. Some of them
> >
> > The ones that matter most are the TLDs and the root.  Those get so
> > many users that they will be caught MITMing, if they do.
>
> I think technically what we care about is the public registries, not the
> TLDs.  This was my point about the public suffix list and DBOUND: that
> we care about .co.uk just as much as we care about .net.
>
> I know that some people use the term TLD to refer to the public
> registries instead of "top-level domains", but i think it's worthwhile
> to be precise in this discussion.
>
> > If evilhosting.com has lots of customers, then they'll help audit it,
> > else they might not.
>
> If evilhosting.com is handing out subdomains to its customers and
> expecting them to act as different administrative sub-zones, then
> evilhosting.com effectively *is* a public registry, and as such it needs
> to be auditable as well.  (it also needs to be considered a public
> registry for the sake of cookies and other same-origin policy things on
> the web, for example, so that jbonneau.evilhosting.com can't set cookies
> that would apply to dkg.evilhosting.com).
>
> > At any rate, the first-order problem in a
> > hierarchical public key system is keeping the roots and intermediates
> > closest to the roots honest.
>
> agreed that the primary concern is transparency, monitoring, and
> auditability of accumulated centralized control.
>
> Who is actually doing the monitoring and auditing is a separate
> question, though.
>
> note that CT appears to differentiate between monitoring (RFC 6962
> section 5.3) and auditing (RFC 6962 section 5.4) in this way:
>
>   Auditors make sure that SCTs are cryptographically valid against an
> STH, and that one STH chains properly to another;
>
>   Monitors make sure that the whole log itself is cryptographically
> valid, looking at all the data.
>
> Neither of these activities describes the actual checks that would need
> to happen for misissuance to be detected.  As noted in section 7.2,
> "interested parties" need to think about how to monitor to ensure that
> items with their administrative domains are not logged by other parties.
>

I think in effect these are monitors - i.e. they see the whole log, and may
as well cryptographically verify it while they do whatever-else-they-do. I
didn't want to specify what you might look for in logged certificates
because I think the answer is "whatever interests you".


>
> If this is neither "Monitoring" nor "Auditing" maybe we need a name for
> this kind of activity, so we can discuss it more directly?  how about
> "misissuance review"?
>
>
> 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?


>  And she also wants to ensure that
> .co.uk is not publishing spoofed records about the example.co.uk zone.


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


>
>         --dkg
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
Certificate Transparency is hiring! Let me know if you're interested.