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

On 13 November 2016 at 06:47, Emily Stark <estark@google.com> wrote:
>> 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.


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

Received on Sunday, 13 November 2016 14:50:28 UTC