Subject: [Trans] Question about PRIVATE option (Ticket #1)

From: Rick Andrews <[email-masked]>
Date: Mon, 10 Mar 2014 11:58:48 -0700

Regarding Issue #1: http://tools.ietf.org/wg/trans/trac/ticket/1# "Need options for avoiding logging private subdomains", I think the design is not yet complete.

I understand how this works when my customer has chosen the precert delivery option (I mask the second level domain in the precert that I send with the add-pre-chain command).

But if my customer has chosen to deliver SCTs via OCSP staple or TLS extension, and they want to keep their subdomain private, what do I do? I'm going to sign the cert without SCTs in it, but if I log it via an add-chain command, the subdomains will be visible in the log.

-Rick

---

From: Rob Stradling <[email-masked]>
Date: Tue, 11 Mar 2014 10:34:14 +0000

Rick, thanks for raising this.  I agree that we need to make the PRIVATE 
option work in these scenarios.  As it happens, I mentioned this to Ben 
just before the trans meeting last week.

My suggestion is that we should permit both Certificate SCTs _and 
Precertificate SCTs_ to be delivered via OCSP Stapling and the TLS 
Extension.

There's no reason why a Precertificate couldn't be issued _after_ the 
corresponding Certificate has been issued!  :-)

Would this work for you?

Slight complication...
In the SCT v1 format, entry_type is "implicit from the context in which 
the SCT is presented."
So, for the above idea to work, we would need to either:
   i) Define SCT v2, in which entry_type is expressed explicitly.
   or
   ii) Define a CtExtensions extension to carry the entry_type 
explicitly in a v1 SCT.
   or
   iii) Expect TLS Clients to attempt to verify v1 SCTs sent via OCSP 
Stapling or the TLS Extension twice (first time, assume entry_type is 
"x509_entry"; if the SCT signature doesn't verify, try again, this time 
assuming entry_type is "precert_entry").

On 10/03/14 18:58, Rick Andrews wrote:
> Regarding Issue #1: _http://tools.ietf.org/wg/trans/trac/ticket/1#_
> “Need options for avoiding logging private subdomains”, I think the
> design is not yet complete.
> I understand how this works when my customer has chosen the precert
> delivery option (I mask the second level domain in the precert that I
> send with the add-pre-chain command).
> But if my customer has chosen to deliver SCTs via OCSP staple or TLS
> extension, and they want to keep their subdomain private, what do I do?
> I’m going to sign the cert without SCTs in it, but if I log it via an
> add-chain command, the subdomains will be visible in the log.
> -Rick

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

---

From: Rick Andrews <[email-masked]>
Date: Tue, 11 Mar 2014 13:35:17 -0700

Rob,

What you're suggesting is that the add-pre-chain command can be used to log a cert that ultimately will not include the SCTs in the final cert? That seems like a path forward.

For the slight complication you describe, I suppose that needs to be added to the issue tracker.

-Rick

> -----Original Message-----
> From: Rob Stradling [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2014 3:34 AM
> To: Rick Andrews; [email-masked]
> Subject: Re: [Trans] Question about PRIVATE option (Ticket #1)
> 
> > "Need options for avoiding logging private subdomains", I think the
> > I'm going to sign the cert without SCTs in it, but if I log it via an

---

From: Rob Stradling <[email-masked]>
Date: Wed, 12 Mar 2014 12:14:22 +0000

On 11/03/14 20:35, Rick Andrews wrote:
> Rob,
>
> What you're suggesting is that the add-pre-chain command can be used to log a cert that ultimately will not include the SCTs in the final cert?

Yes.

> That seems like a path forward.

Great.

> For the slight complication you describe, I suppose that needs to be added to the issue tracker.

Yes.  I just wanted to check that it would work for you before I did that.

I've just added http://trac.tools.ietf.org/wg/trans/trac/ticket/10

> _______________________________________________
> 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: Eran Messeri <[email-masked]>
Date: Wed, 12 Mar 2014 14:23:50 +0000

IMHO Option (ii) is the most straightforward solution. Option (iii) exposes
the client to further complication (supporting private subdomains already
complicates the client code).
For SCT v2 (should we decide to have one) the entry_type could be an
optional field outside the extensions.

On Wed, Mar 12, 2014 at 12:14 PM, Rob Stradling <[email-masked]>wrote:

>> What you're suggesting is that the add-pre-chain command can be used to
>> log a cert that ultimately will not include the SCTs in the final cert?
>>
>
> Yes.
>
>
>>>> extension, and they want to keep their subdomain private, what do I
>>>>
>>> do?
>>>
> 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: Rob Stradling <[email-masked]>
Date: Thu, 13 Mar 2014 09:45:13 +0000

On 12/03/14 14:23, Eran Messeri wrote:
> IMHO Option (ii) is the most straightforward solution. Option (iii)
> exposes the client to further complication (supporting private
> subdomains already complicates the client code).

I agree.

> optional field outside the extensions.

How would you do "optional" in TLS encoding?

I think it would have to be a required 1-byte field.

> On Wed, Mar 12, 2014 at 12:14 PM, Rob Stradling
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         What you're suggesting is that the add-pre-chain command can be
>         used to log a cert that ultimately will not include the SCTs in
>         the final cert?
>
>
>     Yes.
>
>
>     I've just added http://trac.tools.ietf.org/wg/__trans/trac/ticket/10
>     <http://trac.tools.ietf.org/wg/trans/trac/ticket/10>
>
>
>         -Rick
>
>             From: Rob Stradling [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             To: Rick Andrews; [email-masked] <mailto:[email-masked]>
>                 Regarding Issue #1:
>                 _http://tools.ietf.org/wg/__trans/trac/ticket/1#_
>                 <http://tools.ietf.org/wg/trans/trac/ticket/1#_>
>         _________________________________________________
>         Trans mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/trans
>         <https://www.ietf.org/mailman/listinfo/trans>
>
>
>     --
>     Rob Stradling
>     Office Tel: +44.(0)1274.730505 <tel:%2B44.%280%291274.730505>
>     Office Fax: +44.(0)1274.730909 <tel:%2B44.%280%291274.730909>
>     www.comodo.com <http://www.comodo.com>
>
>     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.
>
>
>     _________________________________________________
>     Trans mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/trans
>     <https://www.ietf.org/mailman/listinfo/trans>
>
>
>
>

---

From: Rick Andrews <[email-masked]>
Date: Mon, 17 Mar 2014 16:40:25 -0700

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?

-Rick

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Mar 2014 11:26:20 +0000

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

---

From: Rob Stradling <[email-masked]>
Date: Tue, 18 Mar 2014 12:02:04 +0000

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

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Mar 2014 08:02:45 -0400

On Tue, Mar 18, 2014 at 7:26 AM, Ben Laurie <[email-masked]> 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.
> >

This came up in the DNSOPs meeting. There is a lot of discussion about how
to represent changes of administrative authority in the DNS.

Unfortunately it is focused mostly on fixing cookies which is trying to fix
stupid which is never going to produce a sensible result. But there is
already a zone prefix list used for issue of wildcard certs.

The problem of <private>.<domain>.foo.com looks to me to be the same as the
problem of *.<domain>.foo.com.

*.uk would be a bad thing...

-- 
Website: http://hallambaker.com/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 Mar 2014 12:07:00 -0400

> *.uk would be a bad thing...

the CABForum guidelines split "registry-controlled" zones from the next
level of labels using http://publicsuffix.org/, though they acknowledge
that this is not a scalable long-term solution and something else needs
to be done eventually (see section 11.1.3):

https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf

This idea of a "natural split" between public registries and private
zones is appealing, because of the tradeoffs between auditability and
resistance to zone enumeration.  The entities closer to the root of the
hierarchy need to be audited, since they have power over the leaves; the
entities nearer to the leaves have less power, little or no
responsibility delegated to them from third-parties, and possibly more
legitimate need for hiding individual zone entries or avoiding enumeration.

So how would this work in CT?  if i'm an admin for the example.com zone,
i'd want to monitor the logs for any entries matching:

a) <PRIVATE>.com
b) example.com
c) *.example.com
d) <PRIVATE>.example.com

if any of b, c, or d are observed which were not issued from within my
authority, i now have proof of misissuance, and can take the issuing CA
to task.

But if (a) is observed from monitoring the log, what can the site
operator do?  Do we declare that (a) is indication of log misbehavior?

if so, then we need to also consider that CT-aware TLS clients need to
be able to identify SCTs of the (a) form and report them publicly
somehow, so that log misbehavior is known.  presumably, this would be
the same mechanism used to report an SCT that didn't show up within the
MMD, right?  is there a reporting mechanism defined?

	--dkg

---

From: Ben Laurie <[email-masked]>
Date: Tue, 18 Mar 2014 16:22:12 +0000

> authority, i now have proof of misissuance, and can take the issuing CA

Right.

> operator do?  Do we declare that (a) is indication of log misbehavior?

Surely not - this, again, is misissuance (or misreporting by the CA,
if you prefer). i.e. the CA should be taken to task. The log does not
judge, it merely records.

> somehow, so that log misbehavior is known.

See above. I think these two cases are different.

> presumably, this would be

Currently, only Chrome is implementing CT as a client (to our
knowledge) and so I guess the appropriate recipient of such a report
would be Google. We have not yet defined a way to do this, but
anticipate that Chrome will offer to do it when appropriate.

Another option might be the CA/B Forum.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 Mar 2014 14:47:02 -0400

> On 18 March 2014 16:07, Daniel Kahn Gillmor <[email-masked]> wrote:
 [...]
> judge, it merely records.

hm, i think this introduces a new way that a CA can misissue -- in
particular, it's misissuing a precertificate by putting a <PRIVATE>
label where it should not.

Do you expect the logs to accept (and certify, and publish)
arbitrarily-structured data in the PreCertificate so long as it is
signed by a known CA?  Or will there be some constraints on the data
submitted?

If there are constraints on what kind of precerts a log is willing to
certify, then this would seem to be a reasonable addition to the list of
constraints (though it would be another way that a log could itself
misbehave -- we'd want to add that to the list of things a monitor
should look for).

If the logs just accept and sign this data, what do you suppose should
happen to a CA that has sent a precert of type (a) to the public logs?
It's not clear who was harmed by it (since the actual dNSName used in
the cert itself is not known, right?), and for CT-aware TLS clients that
know to ignore SCTs where <PRIVATE> falls immediately to the left of an
entry in the public suffix list should ignore the SCT anyway.  But
inevitably there will be some clients that see this and don't have an
updated version of the public suffix list, or don't have the ability to
fetch and retain such a thing, and will be fooled by the SCT.

It's very difficult for the domain holder to tell that they have
specifically been harmed in this case (and possibly even difficult to
make a strong case for negative consequences to the issuing CA or
misbehaving log), so it seems like CT isn't fulfilling its mission of
making detection of misissuance isn't being met here.  Or have i missed
something?

> anticipate that Chrome will offer to do it when appropriate.

Given that the scheme's robustness relies on clients reporting errors
(in both the logs or the CAs), i think we need to be clearer about how
such a report should happen.

> Another option might be the CA/B Forum.

End users operating their browsers are not going to know how to send any
kind of report to the CA/B Forum, unless you're suggesting that CA/B
Forum could set up a public repository to hold cryptographically-proven
documentation of misissuance or something, and the submission could be
automated somehow.  I don't know enough about the CA/B Forum to know if
that's within their scope or not.

Regards,

	--dkg

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Mar 2014 12:28:27 +0000

> signed by a known CA?  Or will there be some constraints on the data

It has to look like an X509v3 certificate. But that's about it.

> misbehave -- we'd want to add that to the list of things a monitor

As I said, the function of a log is to record and publish, not to
judge. The main reason we ask for logged items to be signed is to
avoid spam (also, of course, there's not a huge amount of point in
logging things that nothing can be done about, so attribution to a CA
seems useful).

> the cert itself is not known, right?)

That is the the problem surely? The purpose of the log is to ensure
correct issuance. If the logged certificate contains insufficient data
to do that, then the CA is not cooperating.

> and for CT-aware TLS clients that

The SCT does not tell you whether you should accept or reject the
certificate - it merely tells you it was logged. You always have to
check further to discover whether it was OK or not.

> making detection of misissuance isn't being met here.  Or have i missed

I would claim that it is the CA that is not fulfilling its mission (of
logging appropriately). Logs need to be liberal in what they accept
otherwise they become a chokepoint for policy, which is surely not a
desirable outcome.

> such a report should happen.

OK, so I'm not specifying a detailed mechanism for reporting right
now, but clearly one is needed. For now "tell Ben or Chrome team"
seems sufficient. In general, enforcement has to lie with the clients
(and therefore, mostly with the authors of those clients), so I don't
see how I can define a general mechanism for this.

> that's within their scope or not.

I am not expecting end users to have to know anything - I expect
clients to assist them in this matter. Exactly how we will do this in
Chrome has not yet been decided, but clearly we do need to decide it,
and we will.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Mar 2014 14:30:13 +0000

Another way to think about this whole question is this: logging a
precert for <PRIVATE>.x.y is equivalent to creating a name-constrained
intermediate for x.y. If the CA should not have created such an
intermediate, then it also should not have logged the corresponding
precert.