Emily Stark
2018-11-10 19:34:12 UTC
Thanks for the review. Replies inline.
sources. For example, the owner of an Expect-CT host that receives an
"unknown" SCT report should go look up the log policy of the affected UA to
figure out how to fix their SCTs.
https://github.com/httpwg/http-extensions/commit/15a86b656ede69f71897ba1f8cb056cef4844810
https://github.com/httpwg/http-extensions/commit/15a86b656ede69f71897ba1f8cb056cef4844810
by limiting report-uris to HTTPS only.
Alissa Cooper has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
S 2.1.4.
"Expect-CT: max-age=86400, enforce"
Is the whitespace after the comma intentional?
Yes, the examples are intended to show that whitespace is optional.draft-ietf-httpbis-expect-ct-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
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.
As you suggested, I think the information is better gleaned from other"* 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.
sources. For example, the owner of an Expect-CT host that receives an
"unknown" SCT report should go look up the log policy of the affected UA to
figure out how to fix their SCTs.
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.
Fixed in"4.2. Avoiding amplification attacks"
This title seems like a bit of a misnomer given that the attacks can't
be fully avoided.
https://github.com/httpwg/http-extensions/commit/15a86b656ede69f71897ba1f8cb056cef4844810
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.
Fixed in"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.
https://github.com/httpwg/http-extensions/commit/15a86b656ede69f71897ba1f8cb056cef4844810
by limiting report-uris to HTTPS only.