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

[Emily Stark]

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

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.
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/
----------------------------------------------------------------------
----------------------------------------------------------------------
Firstly, thank you for writing this, it is a useful document and provides
an
https://datatracker.ietf.org/doc/review-ietf-httpbis-expect-ct-07-opsdir-lc-wu-2018-08-07/
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.