- 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