Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

From: Rob Stradling <[email-masked]>
Date: Tue, 01 Apr 2014 10:31:24 +0100

On 31/03/14 23:04, Doug Beattie wrote:
> I agree with Peter on this one, why are we making a long human readable
> string for a cert that basically no-body will ever look at and will be used
> only by the browser to validate the SCT (and the CA to create the SCT
> extension)?

I sincerely hope that the end result of the CT effort is _not_ that 
"no-body will ever look at" Precertificates.

If nobody performs the Monitor role (i.e. watching the CT logs for 
Precertificates of interest) then CT won't achieve its potential as an 
effective mechanism for detecting certificate mis-issuance!

Like I said, I'm not too bothered about what string literal we end up 
using.  But since there doesn't seem to be any real need to optimize for 
size, let's prioritize clarity.

Do both "?." and "(PRIVATE)." convey the intending "private 
subdomain(s)" meaning equally well?

> When the browser tries to validate an SSL certificate they need
> an indication that the SCTs were computed normally or via the Private
> algorithm. Aren't all the SANs either private or not in a cert, and not a
> mix?  (sorry if this is in a spec or an email that I missed).

I think we should support a mixture of private and non-private SANs in a 
cert.

> It seems like the indicator to the browser should be at the SCT extension
> level, not on every SAN entry (there could be hundreds), so we could omit
> any indication of private at the per-san level.  If it needs to be at the
> SAN level (for some reason), then put in a valid PrintableString character
> (maybe 2) we'd never expect to see in the wild.
>
> I'm sure I'm missing a key point.

The Certificate needs to indicate, _for each SAN_, the number of domain 
components that are masked in the Precertificate, so that the browser is 
able to reconstruct the Precertificate precisely.

An indicator at the SCT extension level, rather than for each SAN, just 
wouldn't be enough.

> Doug
>
> -----Original Message-----
> From: Trans [mailto:[email-masked]] On Behalf Of Peter Bowen
> Sent: Monday, March 31, 2014 10:57 AM
> To: Rob Stradling
> Cc: [email-masked]; Rick Andrews
> Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)
>
> On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling <[email-masked]>
> wrote:
>> On 31/03/14 14:44, Peter Bowen wrote:
>>> If _completely_hidden_ is the requirement, then I agree that any
>>> option that is no f(x) = 1 (for fixed values of 1) fails.
>>>
>>> Why have the long string "(PRIVATE)" at all then?  Would a single '?'
>>> not be adequate?  I don't think you will ever find '?' in a real
>>> dNSName.
>>
>>
>> "PRIVATE" seemed a good choice of string literal from the point of
>> view of explaining the idea clearly, but I'm not bothered what string
>> literal we end up using.
>>
>> Why does the length of the string literal concern you?
>
> I guess it does not really matter.  I was thinking about the future, when CT
> is used for the CDN certificates with hundreds of SANs.
> Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200 bytes.
> Maybe additional size is not a big deal.
>
> Thanks,
> Peter
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Gervase Markham <[email-masked]>
Date: Tue, 01 Apr 2014 15:54:09 +0200

On 31/03/14 12:10, Rob Stradling wrote:
> How long would it take an attacker to perform a dictionary attack to
> discover that "6f993bb2" corresponds to "mail.corp" ?

If only some correlation is desired, then you could just use e.g. the
last two digits of the checksum. This allows a correct match when in
possession of the correct cert, but also one can imagine many
non-existent certs which would also match.

Gerv

---

From: Rob Stradling <[email-masked]>
Date: Tue, 01 Apr 2014 21:26:32 +0100

> non-existent certs which would also match.

Hi Gerv.  I don't think this is desirable.

Only the domain owner needs to know what the unmasked subdomains are, 
and they can do this by simply looking at the corresponding Certificate.

---

From: Gervase Markham <[email-masked]>
Date: Tue, 01 Apr 2014 21:28:46 +0100

> and they can do this by simply looking at the corresponding Certificate.

Does it not help with your combinatorial explosion, because it's then
much easier to match up a potential cert with its logged precert?

Or am I mistaken?

Gerv

---

From: Rob Stradling <[email-masked]>
Date: Tue, 01 Apr 2014 21:41:10 +0100

> much easier to match up a potential cert with its logged precert?

A TLS client will see only the Certificate, and from that it needs to 
reconstruct the Precertificate.

Yes, the Precertificate is publicly logged, but this doesn't help a TLS 
client that is not allowed to perform blocking side-channel lookups 
during TLS handshakes.

So no, I'm afraid it wouldn't help with the combinatorial explosion. 
(So I'll stick with my original idea for solving that).

---

From: Rick Andrews <[email-masked]>
Date: Tue, 1 Apr 2014 13:42:20 -0700

I would imagine that domain owners would simply use the Issuer Name and Serial Number combination to match the precert to the actual cert. 

-Rick

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2014 1:29 PM
To: Rob Stradling; Peter Bowen; Rick Andrews
Cc: [email-masked]
Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1)

> and they can do this by simply looking at the corresponding Certificate.

Does it not help with your combinatorial explosion, because it's then much easier to match up a potential cert with its logged precert?

Or am I mistaken?

Gerv