Re: Additional comments on draft-stark-expect-ct-00

Thanks, Jeff. Replies inline.

On Wed, Nov 23, 2016 at 4:56 PM, =JeffH <Jeff.Hodges@kingsmountain.com>
wrote:

> Here's some additional comments on "Expect-CT"
> <https://tools.ietf.org/html/draft-stark-expect-ct>
>
> HTH,
>
> =JeffH
>
>
> In the below, "the I-D" refers to the above I-D.
>
> 1. Spec title
>
> Having a title of "HTTP Expect-CT" (HECT) would be more accurate
> because, like HSTS and HPKP, the mechanism is particular to HTTP (and
> actually HTTP-over-secure-transport)
>

Addressed in https://github.com/bifurcation/expect-ct/pull/10


>
>
> 2. Expect-CT header field syntax
>
> The behavior of a valueless Expect-CT header field is presently not
> defined, although it is syntactically correct: both 'enforce' and
> 'report-uri' are OPTIONAL, and 'max-age' is only REQUIRED if 'enforce'
> is present. In HSTS [RFC6797], a valueless strict-transport-security
> header field violates the syntax (because 'max-age' is always required)
> and thus is explicitly ignored.
>

Good point -- I think this issue will go away as I rework the document to
cache report-only headers, at which point max-age will be required.


>
> Also, the Expect-CT syntax presently defines the below as a valid
> Expect-CT header field..
>
>  Expect-CT: enforce; report-uri="https://example.org"; max-age=86400
>
> ..which will ostensibly not yield "report-only" behavior, i.e., UA's
> CT-policy will be enforced AND will submit reports of violations of "the
> UA's CT policy". Is that directive combination intended? If so, perhaps
> this might be termed an "enforce-and-report" expect-ct policy.
>

Yes, that combination is intended. Clarified in https://github.com/bifurcat
ion/expect-ct/pull/11


>
>
> 3. Terminology
>
> The I-D does not have terminology of "known expect-ct host" (as in HSTS &
> HPKP) ?
>
> "known/unknown" can be a useful distinction and spec-writing shorthand,
> see e.g.: <https://tools.ietf.org/html/rfc6797#section-14.3>, the parag
> after the two bulleted parags. I.e. a host can be an "expect-ct host" but
> be unknown as one from the perspective of a particular UA instance.
>
> The I-D could use a terminology section tho I note HPKP [RFC7469] does
> not have one.
>
>
Added a Terminology section and use of Known Expect-CT Host in
https://github.com/bifurcation/expect-ct/pull/12


>
> 4. Is expect-ct policy host-wide or connection-specific?
>
> Is expect-ct policy host-wide, a la HSTS - i.e., applied to all ports
> on a host? Or is it specific to just that particular secure transport
> connection over which the Expect-CT header field was received?  If it is
> connection-specific, should not the port be explicitly part of the
> storage model, as well as the host's domain name?
>
> The I-D implies that expect-ct policy is connection-specific, and that
> makes sense to me because it is specific to characteristics of the server's
> certificate returned on that connection. It would be good to explicitly
> state this.
>

It's currently defined host-wide, which matches HPKP and I think is the
simplest thing to do. (I don't anticipate there being much of a use case
for keying by host+port.) I feel like this is reasonably clear from the
fact that the draft refers to Expect-CT hosts throughout and keys by domain
names, but let me know if there are any places where you think it would be
helpful to clarify this.


>
>
> 5. server-initiated expect-ct policy deletion?
>
> Is there no "max-age=0" ability for an Expect-CT host to signal a UA to
> remove it from the UA's Expect-CT cache?
>

There is; it's in https://tools.ietf.org/html/draft-stark-expect-ct-00#
section-2.3.1 ('If the "max-age" directive has a value of 0...')


>
>
> 6. clarify characteristics of report-only
>
> Emily Stark <estark@google.com> wrote on Monday, November 21, 2016
> at 3:28 PM:
>
>>
>> - Caching in report-only mode: I can be convinced that this is
>> useful, in case where you are e.g. rolling out a CT-compliant
>> certificate in conjunction with Expect-CT (for example if you have a
>>  config that turns on CT and also turns on Expect-CT in report-only
>> mode, and the config didn't make it out to a few of your servers).
>> Will be especially convinced if site owners say that this is how they
>> want it to work.
>>
>
> I am thinking that it would be useful to cache report-only expect-ct
> policies, e.g. to satisfy the above use case.
>
> Thus max-age would be required in the header field value whether either
> or both report-uri and enforce directives are present. (see #2)
>
> And then we can have max-age=0 be the policy deletion mechanism :) (see
> #5).


>
> 7. User agent and server implementation advice, sec cons
>
> The I-D might have similar UA and server implementation
> advice/considerations, as well as security considerations, as HSTS
> and/or HPKP. Something to think about, though I note HPKP does not
> feature distinct UA and server implementation advice/considerations
> sections, though it does have a distinct "privacy considerations" section
> which HSTS lacks.
>

Acknowledged #6 and #7 but haven't actually done them quite yet.


>
>
> end
>
>