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

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.

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

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

Received on Monday, 21 November 2016 23:29:04 UTC