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

Ben Laurie <benl@google.com> Tue, 18 March 2014 11:26 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 DF78E1A03C9 for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 04:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 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, RP_MATCHES_RCVD=-0.547, 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 nI5JtS3Ha4F9 for <trans@ietfa.amsl.com>; Tue, 18 Mar 2014 04:26:29 -0700 (PDT)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6D91A03C7 for <trans@ietf.org>; Tue, 18 Mar 2014 04:26:29 -0700 (PDT)
Received: by mail-ve0-f178.google.com with SMTP id jw12so6805716veb.37 for <trans@ietf.org>; Tue, 18 Mar 2014 04:26:20 -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:content-transfer-encoding; bh=cRSNJKK6OEeSdS0ccaP6ZHHEvmzhumOCSzgQlLLO7BI=; b=J6aCn7MVa13X3uvB6KnVCdvp0opiucIWBlOIt3eNpDdVRC4xE7hHAeeLUAJCJmr3lo BM4HysJsQa1qKXYHj47p9Bqo4ynAyM2S9X4LghRC1YpRpg7qPdXEdE6AnV0Hzy+3JRzj lY8AxYgW6RHsNuhf6kvmYiiDWDiydVapHsFbpNPh0NBjKlykcAURY1sz0gtypTMC4puZ mk05JfEiTRP4pabK4gClVIEiadh7xLT3cL92p2MvBDLCbOKXXEJ0EVi9CTfdtE0ktcfT F67huMNLIOcd7FU9KB/J6ctZvWAVw73d8/1PBNby7D0YDz9QFbSk4qdVCRbDNQ95LYRW CtKg==
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 :content-transfer-encoding; bh=cRSNJKK6OEeSdS0ccaP6ZHHEvmzhumOCSzgQlLLO7BI=; b=JBjQ0bGpHg+EtloDz5LP7wODvIw6Q922ENJb3bkYpKVMOPDGhv1WhK0mUoaidWMmV+ 8kswMPHlr43JNPJiIRrCdIAR+xgnY24Bd8x6mE94+dMZXNLOJ4cQAxt6sdUfb18shxW9 etX9XBffOGpUI2s9bj/rfXmR9ANtlueoDbU7YEvw+FamUQ5aAsfVBKgFpdpvV+u+ZxkU bJJ/Bo8RpMra972QeU4KlTkNtVkJB+x6z4G6NSIno06zea9ccxQlxeZt9OGxsyaXdTW1 GkrhKlP6KwPZvmuV1FVF3wK1KlRlcYNKFMmvgzKxE+TMgAAxPOiceZurzbBOlX9gvfVU H9SA==
X-Gm-Message-State: ALoCoQnC9J9kbv8a/7KCsZrFyJvskT9CzTuN4i3U1cs9BgkHJVIq+6PYCPuQ96IDGLYDc/45B0q+PHhCbVqIUufPhD1xJmt173eAgO48er33HmGaT0v2x8peGs4Q9Aj+1kue5q3yj6C6FCLcBmbESHp4/SfFktPrV3yL1j4FJliD8mLzAzl3MF0APLJrYala7YCKUD3T7idY
MIME-Version: 1.0
X-Received: by 10.221.40.10 with SMTP id to10mr7668107vcb.22.1395141980644; Tue, 18 Mar 2014 04:26:20 -0700 (PDT)
Received: by 10.52.230.105 with HTTP; Tue, 18 Mar 2014 04:26:20 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C7DAA2CF@TUS1XCHEVSPIN33.SYMC.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>
Date: Tue, 18 Mar 2014 11:26:20 +0000
Message-ID: <CABrd9SQONqLvemGtfy6WpyVQEN5Wuq8otFpjA2nKTirF6Z_5Qw@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/x6SqbFXjteI9JELG7QAefdFCcl8
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 11:26:31 -0000

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.

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