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

Phillip Hallam-Baker <hallam@gmail.com> Tue, 18 March 2014 12:02 UTC

Return-Path: <hallam@gmail.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 0C65F1A0323 for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 05:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ilYexdltlGXz for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 05:02:56 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D51A01C0 for <trans@ietf.org>; Tue, 18 Mar 2014 05:02:54 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id 10so4528535lbg.25 for <trans@ietf.org>; Tue, 18 Mar 2014 05:02:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZncLOxdvOsXPOVa/27ZN1FPesrYa5UWJ3oe2s4p1778=; b=q4JrcT8SAoUfN+qplFlJpIPSk7DAPIUmp+7ysmSLgGN26xejaroWn7TMDq4CkHP/Bd +L+zP4jmxfc57Ec1MTj08H+hVMkZ8/D1OOp2S3z1Cn3Yc2UpN4+88XKKHMl9IyCKgPN9 OzuavD++BOn+7nDnVRrkP8rssQiK9dcY1ZQqWzuXmP2ikgtIfMhxhLORtohgB7rzcG3j 1zMThAMd7q7RAmtVdu15DFfIGWcxdWCr6ZlBXZyikljXPwXWW7eUVitkXaANtiHiRtmX w7l7kMWNtNvPjDlhzP79mH/aPY0PI7FWYyn8Xcd2ttcvaBbkfF4kpQqS1Jj8vUjAMe44 x1Tg==
MIME-Version: 1.0
X-Received: by 10.152.18.135 with SMTP id w7mr9430237lad.29.1395144166124; Tue, 18 Mar 2014 05:02:46 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Tue, 18 Mar 2014 05:02:45 -0700 (PDT)
In-Reply-To: <CABrd9SQONqLvemGtfy6WpyVQEN5Wuq8otFpjA2nKTirF6Z_5Qw@mail.gmail.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>
Date: Tue, 18 Mar 2014 08:02:45 -0400
Message-ID: <CAMm+Lwhy+ArnJhY-SjkbPtbZgPfDyZ4LkQ82mNJrvSO7jZr3Bw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary="089e0141a7da6eb3b304f4e050ce"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mHzZ_BFblkVuKB7zMBKBD7JVy_A
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 12:02:59 -0000

On Tue, Mar 18, 2014 at 7:26 AM, Ben Laurie <benl@google.com> wrote:

> On 17 March 2014 23:40, Rick Andrews <Rick_Andrews@symantec.com> wrote:
> > I have another question about the PRIVATE option. While planning the
> implementation of CT with our teams, we first thought that we would use the
> precertificate option as the default for all customers. Our hope was that
> most customers wouldn't even need to be aware of CT; they would get some
> extra data in their cert and there would be no change to deployment (I
> believe that was the hope of the CT designers too).
> >
> > However, the PRIVATE subdomain masking option made us rethink that. If a
> customer wants to keep their fqdn private, they need to make that choice up
> front, before we've issued the cert to them. If they don't choose PRIVATE
> up front, their cert will get logged, and switching to PRIVATE after that
> would be pointless because their fqdn would be public. But that means
> forcing the customer to stop in the middle of the enrollment process, read
> up on CT, and make an informed decision. We're finding it's difficult to
> get most people to understand why they would choose SHA-2 instead of SHA-1,
> and educating them on CT and its options is expected to be far more
> difficult.
> >
> > So we're considering making PRIVATE the default option, or perhaps the
> only option. It's arguably better for customers because it preserves a
> measure of privacy and postpones the time when they have to understand all
> the details of CT. It may be a little more challenging for a domain owner
> monitoring the logs, because they'll only see the precerts with serial
> numbers and no fqdns, but that's not much of a challenge. It makes our
> implementation simpler and therefore easier to test and deploy.
> >
> > Any feedback on this idea?
>
> Interesting. I guess the difficulty would be in deciding how many
> names to elide. For example, consider the uk.com domain vs.
> example.com.
>
> secret.example.uk.com should be registered as <PRIVATE>.example.uk.com
> (since uk.com is effectively a TLD). However,
> secret.verysecret.example.com should be <PRIVATE>.example.com.
>

This came up in the DNSOPs meeting. There is a lot of discussion about how
to represent changes of administrative authority in the DNS.

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

-- 
Website: http://hallambaker.com/