- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Wed, 23 Nov 2016 16:47:07 -0800
- To: IETF HTTP WG <ietf-http-wg@w3.org>
WRT "Expect-CT" <https://tools.ietf.org/html/draft-stark-expect-ct> (aka
"the I-D" in the below)...
Is the expect-ct policy intended to be used long-term by servers?
I.e., is this server-declared expect-ct policy only a stop-gap until all
browsers natively enforce their vendors' "ct policies"?
At first glance, it seems the answer is "yes, expect-ct has long-term
usefulness" given the language in
<https://tools.ietf.org/html/draft-stark-expect-ct-00#section-2.1.2>,
i.e., a host's declaration of expect-ct policy is stating that the UA
must terminate any connection to that host (and port?) that does not
satisfy the UA's ct policy.
However, given this..
On Sunday, November 13, 2016 at 4:47 AM, Emily Stark wrote:
> That is, eventually, when browsers require CT for all certificates,
> [...] 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)
..it sounds like the browsers intend to do that in any case, and if so,
on what timescale?
I.e., is it worthwhile to go through all the work to formally define
Expect-CT in an RFC?
Though, if there is some functionality that a server-declared expect-ct
policy stipulates that is not intended to be implemented by default in
near- to intermediate-term, then formally specifying Expect-CT perhaps
has a reasonable cost-benefit regardless. Or also if explicit
server-declared "expect-ct" policy would be useful to the long-tail of
HTTPS clients other than the dominant browsers.
Perhaps one should consider having the expect-ct policy additionally
mean that there is "no user recourse" to connection termination as a
result of CT-policy violation. I note the I-D does not presently state
that.
See <https://tools.ietf.org/html/rfc6797#section-12.1> for how this is
discussed in HSTS. You might consider adding "no user recourse" to a "UA
implementation advice" section.
Though, like any of this (including HSTS), the browsers could in the
future decide that they will have a "no user recourse" policy by default
for all secure transport establishment failures. It's a question of how
far in the future might that occur (in order to justify
present-to-intermediate-term work).
HTH,
=JeffH
Received on Thursday, 24 November 2016 00:47:47 UTC