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

Expect-CT has usefulness long-term if a browser chooses not to require
CT for all certs, but implements the spec anyway. A browser could
implement Expect-CT by making a minimal policy (perhaps by choosing to
select an intersection of logs trusted by other browsers), and simply
verifying SCT signatures.

-tom

On 24 November 2016 at 20:00, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> Emily wrote:
>> 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.
>
> ok, by "they" you mean UAs, yes?
>
>
>> 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.
>
> by implication you mean "useful" for a server (aka "relying party" (RP)) and
> user, yes?
>
> because what we are protecting here is not so much the browser (vendor) but
> the RP and user, yes?
>
> I could see Expect-CT to be useful for the longer term if it were to signal
> additional RP-desired selective UA behavior such as "no user recourse", *if*
> the browsers were not going to implement such behavior, e.g., as a a matter
> of course in the case of errors during secure connection establishment.
>
> =JeffH
>
>
>
>> On Wed, Nov 23, 2016 at 4:47 PM, =JeffH
>> <Jeff.Hodges@kingsmountain.com> wrote:
>> 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?
>>
>> 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.
>>
>>
>> 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.
>>
>> 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.
>>
>>
>> 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 Saturday, 26 November 2016 03:39:10 UTC