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

[expect-ct] Is expect-ct policy intended for long-term use? (plus: no user recourse)

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Wed, 23 Nov 2016 16:47:07 -0800
To: IETF HTTP WG <ietf-http-wg@w3.org>
Message-ID: <8635e96f-44a0-1024-8cd2-43ed7100679e@KingsMountain.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 24 November 2016 00:47:50 UTC