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

From: Emily Stark <[email-masked]>
Date: Sun, 13 Nov 2016 04:47:25 -0800

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.

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

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

> -Ekr

---

From: Tom Ritter <[email-masked]>
Date: Sun, 13 Nov 2016 08:49:34 -0600

> header to not be served, but maybe that's a failure of imagination on

The behavior of HPKP-RO was considered widely (by everyone except the
authors) to be a mistake. The draft was past Last Call though, and
everyone was exasperated at that point so it was not corrected despite
there generally being consensus otherwise. This thread will give you a
good idea of that discussion:
https://www.ietf.org/mail-archive/web/websec/current/threads.html#02173

Report Only mode should behave the same as Enforcement Mode in all
regards except enforcement. That's the only way site admins will feel
confident that they have a good handle on their configuration not
breaking things.

The most immediate examples of this causing issues is in load-balanced
deployments (such as multicast or IP/TCP-level load balancing) where
Server A is correctly configured but Server B is not.

More comments:

Going with an 'enforce' directive as opposed to a second header
prevents sites from deploying a more conservative enforcing mode and a
more aggressive testing mode. This doesn't seem to be an issue because
there are no knobs except max-age to turn. (Yet?)

There is no includeSubdomains directive (which would also make
persistent of Report-Only very important.) I'm not saying this is bad,
but HSTS and HPKP have the feature. On the other hand - it would
probably necessitate the availability of the two modes...

Like HSTS and HPKP, Expect-CT can be used as a (low-bandwidth)
tracking mechanism, so that should go into Privacy Considerations.

-tom

---

From: Emily Stark <[email-masked]>
Date: Mon, 14 Nov 2016 11:35:53 +0900

> https://www.ietf.org/mail-archive/web/websec/current/threads.html#02173

Thanks for the link. That's helpful context. I took an initial look
through it (need to do a second more careful reading) and so far the
argument that I personally find most convincing is the principle of
least astonishment argument.

> confident that they have a good handle on their configuration not

Note that report-only mode probably has to behave differently than
enforcement mode in at least one way, which is how the headers are
processed when received on a non-CT-compliant connection. An
enforcement header, if received on a connection that is not
CT-compliant, will be ignored, but a RO header should at least cause a
report to be sent. In a world where we cache RO headers, should a RO
header be cached if received on a non-CT-compliant connection?

> Server A is correctly configured but Server B is not.

While I can imagine misconfigurations where Server A is serving
CT-compliant connections and Server B is not, I have some trouble
imagining misconfigurations where Server A is making CT-compliant
connections and Server B is not *and* Server A is serving the header
and Server B is not.

To make this concrete, here are the types of misconfigurations I have
in mind that reporting would help with:
1. A CA or site operator misunderstands a UA's CT policy, or has a bug
in conforming to it, and issues/serves a certificate that violates it.
2. A site operator wants to measure the impact of client clock skew
before turning on enforcement mode. (This is a bit of an edge case, as
I suspect it's not very common that a client clock is wrong in such a
way that the certificate validates but the SCT does not.)
3. A site is serving SCTs via stapled OCSP response or TLS extension
and learn about bugs in their implementation and/or the reliability of
their OCSP responder.

In those situations, there's no reason to think that the violating
connection would not be properly serving the report-only header. And
in situations where the site is not properly serving the report-only
header consistently, caching RO won't help debug that unless the
failure to serve the header correlates with a failure to serve a
CT-compliant connection.

> there are no knobs except max-age to turn. (Yet?)

That was the thinking behind that, yes.

> probably necessitate the availability of the two modes...

Yes. In discussion with other browsers, our priority has been to do
something as simple as possible while still being useful, and we
thought that there might not be high-demand for includeSubDomains. I'd
be interested to hear from site operators whether that's true or not.
As you pointed out, no includeSubDomains also means that there's no
need for two separate headers (and thus no need to define how they
interact with each other, etc.).

> tracking mechanism, so that should go into Privacy Considerations.

Definitely will do. The emptiness of Privacy Considerations at the
moment shouldn't be taken to mean that there are none, just that I
haven't gotten to that section yet. :)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 06:04:43 +0900

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

> different policies in different browsers, at least for some amount of

The problem is that as written the future is likely to involve a lot of
bustage.

> header to not be served, but maybe that's a failure of imagination on

Two different independent servers with the same name behind
a load balancer? Or a server farm where policies are rolled out slowly.

-Ekr

---

From: Emily Stark <[email-masked]>
Date: Tue, 15 Nov 2016 10:50:27 +0900

> the policy should be the same. Is there some compelling use case fo

I think sites will want to roll out HSTS and Expect-CT independently
and gradually. For example sites that already have HSTS enabled with a
long max-age might want to turn on Expect-CT with a short max-age and
gradually increase it. Or vice versa.

Also, this is a bit entangled with the discussion about whether we
need/want includeSubDomains for Expect-CT. If we don't want
includeSubDomains (and I hope that there isn't much demand for it, for
simplicity's sake), then it's confusing that
`Strict-Transport_Security: expect-ct-enforce; includeSubDomains;`
only applies HTTPS upgrades to subdomains and does not apply Expect-CT
to subdomains. If we do want includeSubDomains for Expect-CT, then I
can imagine use cases where HSTS should apply to the entire domain but
not Expect-CT (e.g. a subdomain operated by a third-party which is
HTTPS-enabled but not CT compliant), which suffers from the
aforementioned confusing-ness and also requires a separate
expect-ct-includeSubDomains directive.

> The problem is that as written the future is likely to involve a lot of

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?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Nov 2016 13:53:32 +0900

> require CT for all certificates until they standardize on such a

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

-Ekr

---

From: Emily Stark <[email-masked]>
Date: Mon, 21 Nov 2016 15:28:11 -0800

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.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Nov 2016 11:16:08 -0800

> especially convinced if site owners say that this is how they want it

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.

> 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

---

From: Nick Sullivan <[email-masked]>
Date: Mon, 28 Nov 2016 23:54:50 +0000

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 <[email-masked]> wrote:

> >> >> (
> https://groups.google.com/d/msg/mozilla.dev.security.policy/VJYX1Wnnhiw/ZaJBaKfKBQAJ
> ).