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

Rob Stradling <rob.stradling@comodo.com> Tue, 18 March 2014 12:02 UTC

Return-Path: <rob.stradling@comodo.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 A29421A03BA for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 05:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] 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 ef-ad47ufaz8 for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 05:02:15 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4081A0323 for <trans@ietf.org>; Tue, 18 Mar 2014 05:02:14 -0700 (PDT)
Received: (qmail 22280 invoked by uid 1000); 18 Mar 2014 12:02:04 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 18 Mar 2014 12:02:04 +0000
Message-ID: <532835BC.3000906@comodo.com>
Date: Tue, 18 Mar 2014 12:02:04 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>, Rick Andrews <Rick_Andrews@symantec.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>
In-Reply-To: <CABrd9SQONqLvemGtfy6WpyVQEN5Wuq8otFpjA2nKTirF6Z_5Qw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bvh8RH2PPnJdThOWwUNV66vGAlM
Cc: "trans@ietf.org" <trans@ietf.org>
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:18 -0000

On 18/03/14 11:26, Ben Laurie 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?

I expect we'll enable PRIVATE subdomain masking for many enterprise 
accounts by default, for a preconfigured whitelist of registered domain 
names.

For non-enterprise accounts, we might consider offering PRIVATE as an 
"advanced option", but I don't think we'd enable it by default.

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

The Public Suffix List solves this problem in a lot of cases.  But, 
since the PSL is not perfect, it'd perhaps be unwise to rely solely on 
the PSL to make this decision.

Looking ahead, we can hope that whatever comes out of the IETF DBOUND 
initiative will be sufficiently perfect to enable this to be safely 
automated.  :-)

Until then, I'll be more comfortable with a manually reviewed, 
preconfigured whitelist of registered domain names.

> So, not sure how you would avoid asking the customer something in this
> case, either.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online