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)
Thanks for this work. I'm balloting "Yes", but I have a few minor comments. Substantive: §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? Editorial: - 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)
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)
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". Section 220.127.116.11 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)
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
Thank you for addressing my DISCUSS.
Alvaro Retana No Objection
(Adam Roach) (was Discuss) No Objection
Thanks for addressing my comments and the discuss issue from my review.