Re: Comments on draft-stark-expect-ct-00

On Tue, Nov 15, 2016 at 10:50 AM, Emily Stark <estark@google.com> wrote:

>
> >> (https://groups.google.com/d/msg/mozilla.dev.security.
> policy/VJYX1Wnnhiw/ZaJBaKfKBQAJ).
> >> That is, eventually, when browsers require CT for all certificates,
> >> site owners will have to face this same problem of making sure that
> >> all their certificate chains are compliant with the CT policies of all
> >> the UAs that they care about. So I guess I see the interop problem as
> >> somewhat separate, perhaps something that should be addressed on its
> >> own when the CT ecosystem and implementations have matured enough that
> >> UAs are able to standardize on one policy...?
> >>
> >> To put it another way, I see Expect-CT as a way that individual sites
> >> can opt in to the future early ("the future" being when browsers
> >> require CT for all certificates), and the future is quite possibly
> >> different policies in different browsers, at least for some amount of
> >> time.
> >
> >
> > The problem is that as written the future is likely to involve a lot of
> > bustage.
>
> I feel like maybe I'm not understanding what you'd like to see
> instead. Are you arguing that the Expect-CT draft should contain a
> policy like "all EE certs must come with 2 SCTs from different logs",
> even if that policy differs from what different browsers plan to
> actually enforce for new certificates? Or that browsers shouldn't
> require CT for all certificates until they standardize on such a
> policy?
>

I'm arguing that we shouldn't define a header that says "you must enforce
CT"
without defining what "enforce CT" means.

-Ekr


> >
> >
> >> > S 2.1.3.
> >> > What's the rationale for not caching the directive in report-only
> mode.
> >> > If the purpose of the report-only mode is to tell you when you have
> >> > nonconforming servers, then don't you want to be able to turn it on
> >> > on server A and detect hwen server B is broken? That seems like it
> >> > doesn't work if you don't cache.
> >>
> >> I'm tempted to say "because that's how HPKP does it", but that's
> >> probably not the answer you're looking for. :) I'd expect that sites
> >> would generally serve the report-only header on all responses
> >> unconditionally. I can't really think of a common misconfiguration
> >> scenario that would cause a CT violation and would *also* cause the
> >> header to not be served, but maybe that's a failure of imagination on
> >> my part.
> >
> >
> > Two different independent servers with the same name behind
> > a load balancer? Or a server farm where policies are rolled out slowly.
> >
> > -Ekr
> >
> >>
> >>
> >> >
> >> > -Ekr
> >>
> >
>