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

[=JeffH <[e-mail]>]

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 <[e-mail]> 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