Subject: Re: CT-Policy (was: Comments on draft-stark-expect-ct-00)

From: =JeffH <[email-masked]>
Date: Wed, 23 Nov 2016 18:33:06 -0800

> Do you think it would be reasonable to reference the Chromium +
> Mozilla CT policies but not define a particular policy in a normative
> way?

yep :)

> I maintain that it isn't Expect-CT's place to define a CT policy just
> as it isn't HSTS's place to define what goes in a trust store,

agreed.

> but I'm totally open to having the draft discuss some of the factors
> that browsers should consider when choosing a policy.

yes, I think that'd be good, at least to illustrate what UAs' CT 
policies might entail.

> On Wed, Nov 23, 2016 at 4:29 PM, =JeffH
> <[email-masked]> wrote: "Expect-CT"
> <https://tools.ietf.org/html/draft-stark-expect-ct> (aka "the I-D" in
> the below) uses the term "CT policy" in many places but does not
> define the meaning of the term, as noted by EKR.
>
> On Tuesday, November 15, 2016 at 1:53 PM EKR wrote:
>>
>> I'm arguing that we shouldn't define a header that says "you must
>> enforce CT" without defining what "enforce CT" means.
>
> Agreed.
>
> Emily Stark <[email-masked]> also wrote on Monday, November 21,
> 2016 at 3:28 PM:
>>
>> - Policy: One can draw an analogy to HSTS, where a site promises
>> to provide a certificate that is valid according to the client's
>> definition of valid, including factors that vary across clients
>> (variations in trust stores, SHA1 deprecation, etc.).
>
> Although I would not characterize HSTS policy in that fashion (i.e.,
> see <https://tools.ietf.org/html/rfc6797#section-5.2>), I agree there
> are (some) variations in UAs' contextual determination of whether any
> error conditions arise during secure channel establishment.
>
>> In practice, I don't think CT will be more of a foot-gun than HSTS
>> (and certainly much less than HPKP) because browsers are in close
>> collaboration to work out policies that play nicely with each
>> other.
>
> Hopefully that is the case.
>
> I note the present Chrome CT Policy is here:
>
> Certificate Transparency in Chrome
> <https://a77db9aa-a-7b23c8ea-s-sites.googlegroups.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy/CTPolicyMay2016edition.pdf>
>
>  A first draft of the Mozilla CT Policy is here:
> <https://docs.google.com/document/d/1rnqYYwscAx8WhS-MCdTiNzYQus9e37HuVyafQvEeNro>
>
>(see also: 
<https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/waQ5oqg-USg>)
>
> And discussions of CT policy overall are occurring on: "Certificate
> Transparency Policy" <[email-masked]>
>
> The I-D should reference them in some fashion. The Moz draft has CT
> and CT background info that may be useful to borrow for the I-D or
> explicitly reference.
>
>
> Hm, it seems the term "CT qualified" (or "CT-qualified" (sigh)) -- as
> in a "CT qualified certificate" -- has traction with both GOOG and
> Moz, perhaps it ought to be employed as appropriate in the I-D.
>
>
> HTH,
>
> =JeffH

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Nov 2016 14:42:26 +1100

>> Mozilla CT policies but not define a particular policy in a normative

If HSTS is our benchmark, and that benchmark is so nebulous then it's
a bad one.  The objection that ekr raised was fair: how do I know what
baseline I have to reach in order to avoid the footgun.

Maybe there are weasel words that can be used to allow browsers to
choose their own logs.  But can we at least write down the basics: the
certificate is logged, the TLS handshake includes an SCT, etc...
Surely the current set of policies indicates a common set of
principles that can be written into a specification.

If we're well outside 6962 territory and into policy land, at least
proscribe what falls into policy.  Reading the Mozilla policy, it
seems like number and choice of logs might be the only places where
variation is possible.

---

From: Emily Stark <[email-masked]>
Date: Thu, 24 Nov 2016 07:52:43 -0800

> principles that can be written into a specification.

Are you imagining that this common set of principles is the minimum policy
that a UA should enforce for an Expect-CT host, or the literal policy?

If the former, then it doesn't really solve the problem: it doesn't give
you enough information to know what baseline you have to reach in order to
avoid the footgun. If the spec says that the TLS handshake must include an
SCT, but in practice all browsers require 2 SCTs with requirements on what
logs those SCTs come from, then we haven't really helped anyone out.

If the latter, then we end up in a weird place if a UA wants to enforce a
stricter policy for all certificates. Expect-CT hosts shouldn't be subject
to a looser policy (e.g. one SCT required) than the policy that the UA uses
more generally.

But I do think it would be reasonable to advise site operators of the shape
that a CT policy generally takes and what the moving parts are in practice
(which is maybe what your point below is getting at).

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 Nov 2016 11:55:25 +1100

> (which is maybe what your point below is getting at).

Yes.  This.

Ideally it would also describe the maximal policy, so an operator
could know where the bar is.  But that's impossible without
enumerating the set of possible log operators and I don't think we
want that.