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
and will publish a new version after addressing other review comments.


On Wed, Sep 12, 2018 at 9:54 AM Warren Kumari <> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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:
> 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: implments
> Expect-CT
> -- the "obvious" report-uri is - 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.

Received on Monday, 29 October 2018 03:09:17 UTC