Re: [Trans] Another Question about the PRIVATE option (Ticket #1)

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 18 March 2014 16:07 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 060FB1A040A for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 09:07:23 -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 PPxnkGztU8au for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 09:07:20 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 029D81A02F5 for <trans@ietf.org>; Tue, 18 Mar 2014 09:07:20 -0700 (PDT)
Received: from [10.70.10.55] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 20539F984; Tue, 18 Mar 2014 12:07:10 -0400 (EDT)
Message-ID: <53286F24.5080407@fifthhorseman.net>
Date: Tue, 18 Mar 2014 12:07:00 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>, Ben Laurie <benl@google.com>
References: <544B0DD62A64C1448B2DA253C011414607C70EAF9E@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <531EE6A6.7000007@comodo.com> <544B0DD62A64C1448B2DA253C011414607C77BCCBE@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53204F9E.7000507@comodo.com> <CALzYgEf-=7+XpBYgV-+0ijq-whRsn9gam7AELERZfof-TJ5uEg@mail.gmail.com> <53217E29.7040004@comodo.com> <544B0DD62A64C1448B2DA253C011414607C7DAA2CF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CABrd9SQONqLvemGtfy6WpyVQEN5Wuq8otFpjA2nKTirF6Z_5Qw@mail.gmail.com> <CAMm+Lwhy+ArnJhY-SjkbPtbZgPfDyZ4LkQ82mNJrvSO7jZr3Bw@mail.gmail.com>
In-Reply-To: <CAMm+Lwhy+ArnJhY-SjkbPtbZgPfDyZ4LkQ82mNJrvSO7jZr3Bw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="BADIcxBrKwcSdQwGUVRTjl6h14eWV8GTO"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7DXQUoVwnscZ8qtuRfi7FmFo6Io
Cc: "trans@ietf.org" <trans@ietf.org>, Rick Andrews <Rick_Andrews@symantec.com>
Subject: Re: [Trans] Another Question about the PRIVATE option (Ticket #1)
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, 18 Mar 2014 16:07:23 -0000

On 03/18/2014 08:02 AM, Phillip Hallam-Baker wrote:

> Unfortunately it is focused mostly on fixing cookies which is trying to fix
> stupid which is never going to produce a sensible result. But there is
> already a zone prefix list used for issue of wildcard certs.
> 
> The problem of <private>.<domain>.foo.com looks to me to be the same as the
> problem of *.<domain>.foo.com.
> 
> *.uk would be a bad thing...

the CABForum guidelines split "registry-controlled" zones from the next
level of labels using http://publicsuffix.org/, though they acknowledge
that this is not a scalable long-term solution and something else needs
to be done eventually (see section 11.1.3):

https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf

This idea of a "natural split" between public registries and private
zones is appealing, because of the tradeoffs between auditability and
resistance to zone enumeration.  The entities closer to the root of the
hierarchy need to be audited, since they have power over the leaves; the
entities nearer to the leaves have less power, little or no
responsibility delegated to them from third-parties, and possibly more
legitimate need for hiding individual zone entries or avoiding enumeration.

So how would this work in CT?  if i'm an admin for the example.com zone,
i'd want to monitor the logs for any entries matching:

a) <PRIVATE>.com
b) example.com
c) *.example.com
d) <PRIVATE>.example.com

if any of b, c, or d are observed which were not issued from within my
authority, i now have proof of misissuance, and can take the issuing CA
to task.

But if (a) is observed from monitoring the log, what can the site
operator do?  Do we declare that (a) is indication of log misbehavior?

if so, then we need to also consider that CT-aware TLS clients need to
be able to identify SCTs of the (a) form and report them publicly
somehow, so that log misbehavior is known.  presumably, this would be
the same mechanism used to report an SCT that didn't show up within the
MMD, right?  is there a reporting mechanism defined?

	--dkg