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

Cloudflare is considering using this header in report-only mode to help
identify issues in our CT-stapling infrastructure. This data will help us
with future CT decisions.

We would naturally expect report-only and enforce mode to have the same
semantics, which includes caching. Although our CT-stapling and
header-adding infrastructures are de-coupled, there is a use case for
caching report-only headers: load balancing. Our connections are load
balanced, so subsequent connections may not end up on the same server as
the previous connection. Cached enforcement headers would help us catch
issues where both the CT-stapling configuration and the header-adding
configuration failed to run on a server. With caching, it's more likely
that a
that server with a broken CT config will end up handling resumed connection
from a user agent that had previously connected to a properly-configured
server that that had set the header.

Nick

On Fri, Nov 25, 2016 at 11:21 AM Eric Rescorla <ekr@rtfm.com> wrote:

> On Mon, Nov 21, 2016 at 3:28 PM, Emily Stark <estark@google.com> wrote:
>
> Summarizing some hallway conversations from IETF:
>
> - Caching in report-only mode: I can be convinced that this is useful,
> in case where you are e.g. rolling out a CT-compliant certificate in
> conjunction with Expect-CT (for example if you have a config that
> turns on CT and also turns on Expect-CT in report-only mode, and the
> config didn't make it out to a few of your servers). Will be
> especially convinced if site owners say that this is how they want it
> to work.
>
>
> I'd in general be interested in hearing from site owners on how they
> feel about this header. That would be a good addition to this discussion.
>
>
> - 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.). 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.
>
>
> I'm not sure how strong the analogy is here. It's actually a nontrivial
> inconvenience
> for sites that different browsers have different policies. With that said,
> it's not something
> I'm willing to make a big deal of if the send of the WG is otherwise.
>
> -Ekr
>
>
>
> On Mon, Nov 14, 2016 at 8:53 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> > 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
> >> >>
> >> >
> >
> >
>
>