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

On Sun, Nov 13, 2016 at 9:47 PM, Emily Stark <estark@google.com> wrote:

> Hi, thanks for the comments. Replies inline.
>
> > Overall:
> > Is there a reason to not have this be attached to the HSTS header (or,
> > I guess more weakly to HPKP)?  The syntax seems like it allows it. It
> > seems like we go to all the trouble of making these headers extensible
> > (indeed, the syntax in S 2.1) seems almost identical to HSTS but then
> > we define a new header each time.
>
> If we try to attach it to HSTS or HPKP, the syntax gets kind of
> clunky, which according to my understanding is one of the main reasons
> that HPKP ended up as a separate header too. For example, one might
> want separate max-ages for HSTS and Expect-CT, and one might want to
> configure a report-uri but it should be clear that the report-uri
> applies to Expect-CT but not to HSTS, and then you end up with
> something like this:
>
> Strict-Transport-Security: max-age=31536000; expect-ct-enforce;
> expect-ct-max-age=86400; expect-ct-report-uri=https://...
>
> which I don't think would be the end of the world, but it does feel
> kind of clunky and error-prone to me.
>

In general, my intuition would be that all these parameters other than
the policy should be the same. Is there some compelling use case fo
why they should not?


> At least, it would be nice to merge the report-uri function/description.
> > I am probably missing something, but I don't see the text that defines
> > what the actual semantics of enforcing CT are. The document says stuff
> > like "The UA evaluates each connection to an Expect-CT host for
> > compliance with the UA's Certificate Transparency (CT) policy" which
> > leads me to believe that different UAs might have different policies.
> > Assuming I am correct, this seems like a recipe for interop problems,
> > even with the compliance checking in S 2.3.1. Consider the case where
> > a UA's policy is that you must have CT for every cert in the chain
> > and the operator has two certs, one from a CA which has CT for every
> > cert in the chain and another from a CA which has CT just for the EE
> > cert. If the client gets Expect-CT from a host with the first cert,
> > then it will fail trying to connect to a host with the second cert.
>
> It is indeed the intention that different UAs can have different
> policies. I think this reflects the reality that browser are not
> necessarily planning to have identical CT policies
> (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.


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