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

On Wed, Nov 23, 2016 at 7:42 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 24 November 2016 at 13:33, =JeffH <Jeff.Hodges@kingsmountain.com>
> wrote:
> >> 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 :)
>
> 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.
>

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


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