Re: Opsdir last call review of draft-ietf-httpbis-expect-ct-07

[Emily Stark <[e-mail]>]

Thanks for the comments! I've addressed these in
https://github.com/httpwg/http-extensions/commit/50c233544c746ed826b9b2b778ace17e0b65f66b,
with some replies inline.

On Tue, Aug 7, 2018 at 11:13 PM Qin Wu <[e-mail]> wrote:

> Reviewer: Qin Wu
> Review result: Ready
>
> I have reviewed this document as part of the Operational directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
>
> This document defines"Expect-CT" response header field. It can be used by
> server to indicate that UAs should evaluate connections to the host
> emitting
> the header field for CT compliance. I believe this document is ready for
> publication. However I have a few comments which I like authors of this
> document can consider: 1.Section 1, Introduction,3 paragraph said: "Web
> host
> operators are
>    advised to deploy Expect-CT with caution, by using the reporting
>    feature and gradually increasing the interval where the UA remembers
>    the host as a Known Expect-CT Host.
> "
> To consistent with the next sentence in paragraph 3, s/caution/precautions
> I believe this interval is related to max-age, if the answer is yes, I
> would
> suggest to change interval into waiting time or hold on time, in addition,
> change remembers into regards
>
> 2.Section 2.1 Expected-CT field syntax
> Not sure Response header field name should use upper case.
>

I'm not sure what this is referring to -- the only capitalized bit I see is
the section name, which is capitalized like all the other section names.


>
> 3.Section 2.1.2 said:
> "When both the "enforce" directive and "report-uri" directive
>    (as defined in Figure 2) are present, the configuration is referred
>    to as an "enforce-and-report" configuration"
>
> Section 3, failure-mode said:
> "
>    o  "failure-mode": the value indicates whether the Expect-CT report
>       was triggered by an Expect-CT policy in enforce or report-only
>       mode.  The value is provided as a string.  The UA MUST set this
>       value to "enforce" if the Expect-CT metadata indicates an
>       "enforce" configuration, and "report-only" otherwise.
> "
> I am wondering how these two quoted text related to each other? Why
> failure-mode doesn't support enforce-and-report mode?


"enforce-and-report" mode is implicit when a report is sent with
"failure-mode" set to "enforce"; if it were enforce only mode without
reporting, a report wouldn't be sent.


> 4.Section 3.1 s/reporting
> server/report server 5.Section 4.1 Section 4.1 said UA experience denials
> of
> service. Section 7 said: " 7.  Usability Considerations
>
>    When the UA detects a Known Expect-CT Host in violation of the UA's
>    CT Policy, users will experience denials of service.  It is advisable
>    for UAs to explain the reason why.
>
> "
> Section 5 last paragraph said:
> "Because Expect-CT causes remotely-detectable behavior, it's advisable
>    that UAs offer a way for privacy-sensitive users to clear currently
>    noted Expect-CT hosts, and allow users to query the current state of
>    Known Expect-CT Hosts.
> "
> I am wondering who experience denials of service, who are users referred in
> section 7? Expect-CT hosts or report server? Who are privacy-sensitive
> users in
> section 5? UA? From where can the user query the current state of Known
> Expect-CT Hosts? Report server or Server? Does this document define
> mechanism
> which allow user to get access to the current state of known expected-ct
> hosts?
>
> 6. Section 7 said:
> "
> It is advisable for UAs to explain the reason why.
> "
> Explain the reason why to who? Web client or webserver? If it is the
> latter,Isn’t violation report defined in section 3.2 and 3.3 doing this
> job? If
> it is former,does this introduce security risk?
>

"Users" is meant to refer to end users in these sentences, so I've
clarified that in the text. It's advised that the user can query the
current state of Known Expect-CT Hosts via the UA, e.g. the UA provides a
debugging or configuration functionality where the user can view the hosts
that the UA has noted as Known Expect-CT Hosts, but the document doesn't
define the exact mechanism for how this is done.