Expect-CT Extension for HTTP

Note: This ballot was opened for revision 07 and is now closed.

(Ben Campbell) Yes

Comment (2018-09-11 for -07)
No email
send info
Thanks for this work. I'm balloting "Yes", but I have a few minor comments.


§2.1, step 6: Is there no room for local policy here?

§2.1.3: The guidance for max-age in the security considerations section suggests 30 days is a good value. But the directive is specified in seconds. Does that make sense? Would a 1 second max-age ever be reasonable? Or even 30 days + 1 second?


- General: This uses a non-standard section order towards the end. Conventionally the last 2 sections should be security considerations and IANA considerations (although the order between those two varies.)

§2.2.2: The second sentence is about UA behavior. It seems like that belongs somewhere under §2.3.

§2.3: "SHALL be canonicalized"
By the UA?  (The use of passive voice here obscures the actor.)

(Mirja Kühlewind) Yes

(Terry Manderson) Yes

(Alexey Melnikov) Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-09-12 for -07)
No email
send info
S 2.1.4.
   "Expect-CT: max-age=86400, enforce"

Is the whitespace after the comma intentional?

S 3.1.
      "*  The "status" key, with a string value that the UA MUST set to
         one of the following values: "unknown" (indicating that the UA
         does not have or does not trust the public key of the log from
         which the SCT was issued), "valid" (indicating that the UA
         successfully validated the SCT as described in Section 5.2 of
         [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or
         "invalid" (indicating that the SCT validation failed because
         of, e.g., a bad signature)."

I'm surprised that the state of "does not have public key" and "does
not trust public key" don't have independent value from each other
such that a single status value is sufficient to cover both. Are there
no cases where the difference between these states would be material?
I guess this information could be gleaned in other ways aside from
this kind of report, but I'm still curious about this.

S 4.2.
    "4.2.  Avoiding amplification attacks"

This title seems like a bit of a misnomer given that the attacks can't
be fully avoided.

S 5.
  "Additionally, reports submitted to the "report-uri" could reveal
   information to a third party about which webpage is being accessed
   and by which IP address, by using individual "report-uri" values for
   individually-tracked pages.  This information could be leaked even if
   client-side scripting were disabled."

Isn't there a more generalized potential privacy exposure here if the
report-uri uses HTTP rather than HTTPS? That is, the whole report
could be exposed to any observer even without individual report-uri
values for individual pages.

Benjamin Kaduk (was Discuss) No Objection

Comment (2018-11-10 for -07)
No email
send info
My Discuss point is resolved in the editor's copy, so clearing.

Original Comment preserved below.

Some section-by-section comments:

Section 1

I should probably defer to the HTTP experts in the room, but I was not sure
if it is better to say that we are defining a new "HTTP header field" or a
new "HTTP response header field".

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text.

Section 1.2

The "Certificate Transparency Policy" definition implicitly assumes that
SCTs will be served on TLS connections, as opposed to obtained out of band
(perhaps via a UA-side cache).  This doesn't seem immediately problematic,
but perhaps a more generic definition is advisable.

Section 2.1

Please also note that the '#' ABNF extension is specified in Section 7 of
RFC 7230.
Also, since the 'max-age' directive is required, are the semantics actually
just "#" or would "1#" be more accurate?

   4.  UAs MUST ignore any header fields containing directives, or other
       header field value data, that do not conform to the syntax
       defined in this specification.  In particular, UAs must not
       attempt to fix malformed header fields.

seems like a candidate for RFC2119 "MUST NOT".


   If the substring matching the host production from the Request-URI
   (of the message to which the host responded) does not congruently
   match an existing Known Expect-CT Host's domain name, [...]

I'm having trouble parsing "production" -- is this a term of art I need to
look up?

Section 3.1

What's the extension model for the JSON report objects (e.g., if a new
"source" value needs to be defined, or a new CT version is published)?

Also, for the base64 encoded fields, are trailing '='s stripped (or do we
not care)?

Section 3.3

It's strange to say that the server MAY discard reports with "test-report"
set to true, and then not say at all what the server is supposed to do when
"test-report" is false or absent.

Section 5

   Expect-CT can be used to infer what Certificate Transparency policy
   is in use, [...]

In use by whom; the UA?

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2018-09-12 for -07)
No email
send info
Firstly, thank you for writing this, it is a useful document and provides an important method.
Also thanks to Qin Wu for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-httpbis-expect-ct-07-opsdir-lc-wu-2018-08-07/

I had a few comments and questions:
Section 2.1.  Response Header Field Syntax
Bullet 4: "In particular, UAs must not attempt to fix malformed header fields."
Yah, I fully agree, but it seems like that should be a MUST NOT - I guess the "UAs MUST ignore..." mitigates this, but any reason not to have it stronger?

Section 2.1.1.  The report-uri Directive
HSTS seems to be undefined -- this leads me to a larger point -- I think that it would be very valuable to draw a comparison between HSTS and Expect-CT in the introduction -- they work in a somewhat related manner, and would make it easier (IMO) for newcomers to understand the utility of this.

"UAs SHOULD make their best effort to report Expect-CT failures to the "report-uri", but they may fail to report in exceptional conditions.
 For example, if connecting to the "report-uri" itself incurs an  Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. "
This might be the bad-idea fariy visiting, but perhaps reporting under an Expect-CT failure should be allowed. e.g: www.example.com implments Expect-CT -- the "obvious" report-uri is www.example.com/ct-failed - but this won't actully get reports of failures, because, well, failures :-P
If you don't like the above (and I **fully** see why you might not), perhaps a strong operational recommendation to have the report-uri be some other host is in order? Preventing foot cannons good....

"UAs SHOULD limit the rate at which they send reports.  For example,
   it is unnecessary to send the same report to the same "report-uri"
   more than once."  - once in what period? Connection? Before it gets expired?

Section 2.2.  Server Processing Model
Should this be "Host Processing Model" for consistency?

Section 3.2.  Sending a violation report
"The UA SHOULD report an Expect-CT failure when a connection to a
Known Expect-CT Host does not comply with the UA’s CT Policy and the
host’s Expect-CT metadata contains a "report-uri".  Additionally, the
UA SHOULD report an Expect-CT failure when it receives an Expect-CT
header field which contains the "report-uri" directive over a
connection that does not comply with the UA’s CT Policy."

Can this be reworded somehow? I don't have a suggestion because I read it multiple times and am not sure I understand the difference between the first and second sentence. I started writing it down and drawing circles and arrows and a paragraph on the back of each one before decided this means it isn't clear.

(Eric Rescorla) (was Discuss) No Objection

Comment (2018-12-20)
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2018-12-13)
Thanks for addressing my comments and the discuss issue from my review.

Martin Vigoureux No Objection