Re: Alissa Cooper's No Objection on draft-ietf-httpbis-expect-ct-07: (with COMMENT)

[Emily Stark <[e-mail]>]

Thanks for the review. Replies inline.

On Wed, Sep 12, 2018 at 11:19 AM Alissa Cooper <[e-mail]> wrote:

> 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.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.


>
> 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
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
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
https://github.com/httpwg/http-extensions/commit/15a86b656ede69f71897ba1f8cb056cef4844810
by limiting report-uris to HTTPS only.