W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Comments on draft-stark-expect-ct-00

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 9 Nov 2016 16:57:25 -0800
Message-ID: <CABcZeBMGWoXgd+O5CS44XKRKZYkXy7guB5hcoFL7ptkwcSSsDQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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.

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.


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.

-Ekr
Received on Thursday, 10 November 2016 00:58:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 November 2016 00:58:43 UTC