Subject: [Trans] Masking of private subdomains

From: Rick Andrews <[email-masked]>
Date: Wed, 19 Mar 2014 14:13:46 -0700

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

---

From: Rob Stradling <[email-masked]>
Date: Thu, 20 Mar 2014 12:12:05 +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!

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

---

From: Rick Andrews <[email-masked]>
Date: Thu, 20 Mar 2014 11:53:08 -0700

OK, then, to answer my second question, we'd have to put each masked SAN in the precert even if they were identical:
 	SAN1=<PRIVATE>.example.com
 	SAN2=<PRIVATE>.example.com
 	SAN3=<PRIVATE>.example.com

I see the need for the array of the number of masked domain components, but it complicates the code.

-Rick

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 5:12 AM
To: Rick Andrews; [email-masked]
Subject: Re: [Trans] Masking of private subdomains

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

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.

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!