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

Hi Warren,

Thanks for the comments. I've addressed these in
https://github.com/httpwg/http-extensions/commit/736acd060522d9bdfebfa4ca3d43bbe556043a0a
and will publish a new version after addressing other review comments.

Emily

On Wed, Sep 12, 2018 at 9:54 AM Warren Kumari <warren@kumari.net> wrote:

> Warren Kumari 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:
> ----------------------------------------------------------------------
>
> 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.
>
>
>