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

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

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)

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.

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.

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.

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.

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?

6. clarify characteristics of report-only

Emily Stark <[email-masked]> 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.

end

---

From: Emily Stark <[email-masked]>
Date: Wed, 30 Nov 2016 13:37:39 -0800

Thanks, Jeff. Replies inline.

> actually HTTP-over-secure-transport)

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

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

> 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) ?
>
> 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.
>
Added a Terminology section and use of Known Expect-CT Host in
https://github.com/bifurcation/expect-ct/pull/12

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

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

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