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

From: =JeffH <[email-masked]>
Date: Wed, 23 Nov 2016 16:47:07 -0800

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

---

From: Emily Stark <[email-masked]>
Date: Wed, 23 Nov 2016 17:03:27 -0800

I anticipate Expect-CT to be useful more than a year and less than 5 years.
Within 1-2 years, I expect/hope several browsers will be requiring CT for
all new certificates. They can still implement Expect-CT to protect sites
against backdating and against certificates that were issued before the
date that they started requiring CT for all new certs.

Once a browser is requiring CT for *all* certificates (e.g. because the
maximum validity period has elapsed beyond the date that the browser began
requiring CT for all new certs), then I don't think Expect-CT is useful for
that browser anymore.

On Wed, Nov 23, 2016 at 4:47 PM, =JeffH <[email-masked]>
wrote:

> ..it sounds like the browsers intend to do that in any case, and if so, on
> what timescale?
>

I'm not sure. This is part of the reason why I uploaded this as an
experimental draft. I'm not 100% sure what's the right process or venue is
for a mechanism that is not meant to stick around forever.

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

That seems reasonable to include, though I don't think "no user recourse"
is enough benefit to justify keeping Expect-CT around after it has
otherwise exhausted its usefulness.

> for all secure transport establishment failures. It's a question of how far
> in the future might that occur (in order to justify