Re: [Trans] Masking of private subdomains

Rob Stradling <rob.stradling@comodo.com> Thu, 20 March 2014 12:12 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 5D3B61A071B for <trans@ietfa.amsl.com>; Thu, 20 Mar 2014 05:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.69
X-Spam-Level:
X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, 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 zK0BjMHmggPF for <trans@ietfa.amsl.com>; Thu, 20 Mar 2014 05:12:17 -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 3C5DC1A0545 for <trans@ietf.org>; Thu, 20 Mar 2014 05:12:16 -0700 (PDT)
Received: (qmail 6952 invoked by uid 1000); 20 Mar 2014 12:12:05 -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; Thu, 20 Mar 2014 12:12:05 +0000
Message-ID: <532ADB15.8030302@comodo.com>
Date: Thu, 20 Mar 2014 12:12:05 +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: Rick Andrews <Rick_Andrews@symantec.com>, "trans@ietf.org" <trans@ietf.org>
References: <544B0DD62A64C1448B2DA253C011414607C7F65A0D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C7F65A0D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ALtF6poZyhCL9u6Brb4MfyF41T4
Subject: Re: [Trans] Masking of private subdomains
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: Thu, 20 Mar 2014 12:12:22 -0000

Rick, I agree that the number of masked domain components is not 
especially interesting to some of the participants in the CT ecosystem.

Here's why I proposed it...

When a TLS Client encounters a Certificate that contains Precertificate 
SCT(s), it needs to be able to precisely reconstruct the Precertificate 
(using only the Certificate) in order to verify those Precertificate SCT(s).

If the TLS Client doesn't know the exact number of domain components 
that are masked in the Precertificate, it would have to make multiple 
attempts at Precertificate reconstruction and SCT signature verification.
e.g.
first attempt: Try "SAN:dNSName=top.secret.example.com"
second attempt: Try "SAN:dNSName=<PRIVATE>.secret.example.com"
third attempt: Try "SAN:dNSName=<PRIVATE>.example.com"
fourth attempt: Try "SAN:dNSName=<PRIVATE>.com"

For a multi-domain certificate that has domain components masked for 
many/all of the domains, there would be a cartesian explosion in the 
required number of attempts.

Now, I'm sure it would be possible to write TLS Client code to do the 
cartesian explosion thing, but it would certainly be sub-optimal!

On 19/03/14 21:13, Rick Andrews wrote:
> Rob Stradling has proposed:
> "The PreCertificate could contain SAN:dNSName=<PRIVATE>.customer.com (I mean the literal string "<PRIVATE>"), and the real certificate could contain:
> 	•SAN:dNSName=top.secret.customer.com
> 	•an extension that records the mapping between "top.secret" and "<PRIVATE>". I suggest a SEQUENCE of INTEGERs, one for each Subject:commonName and SAN:dNSName (and in the same order that they appear in the cert), indicating how many leftmost domain components are masked."
>
> 1) I agree there should be an extension to alert clients to the fact that a subdomain has been masked, but I'm not sure I see the value in knowing how many leftmost domain components are masked. A monitor will notify the domain owner that a certificate appeared in the log for their domain, with serial number 1234. The domain owner will then search through their list of known certificates for one issued by that CA cert with that serial number. Knowing the number of masked subdomains is of little or no value.
>
> 2) Consider a case where a cert contains multiple SANs from the same domain, all of which are to be masked:
> 	SAN1=foo.example.com
> 	SAN2=bar.example.com
> 	SAN3=foo.bar.example.com
> All would be replaced with the same masked value. Should the precertificate hold duplicate information, like this:
> 	SAN1=<PRIVATE>.example.com
> 	SAN2=<PRIVATE>.example.com
> 	SAN3=<PRIVATE>.example.com
> Or should it contain only one <PRIVATE>.example.com? What's the value in knowing the number of SANs in the cert if they're all masked?
>
> -Rick

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