Various editorial comments on -06

[jeff.hodges@…]

​https://www.ietf.org/mail-archive/web/websec/current/msg01092.html - paul hoffman

Editorial:

"annunciate" (used a few times) is a fancy word for "announce". Maybe use the far more common word instead.

In section 3.1, "suboptimal downside" is unclear. Is there an optimal downside? I suggest replacing it with "negative".

The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are used in 11.1 and 11.3. This should be an easy fix.

​https://www.ietf.org/mail-archive/web/websec/current/msg01093.html - yoav nir

Editorial:

In the introduction 2nd paragraph it says "(although modulo other rules)". s/modulo/subject to/.

Also, replace "annunciate" with "announce" or "indicate".

Both the introduction and section 8.2 say the policy applies to "all TCP ports". Hosts have multiple TCP ports: for SSH as an example. I suggest we change to "all HTTP(S) ports"

In the title of section 8.5, I think we can do without the word "Interstitially".

Section 10.1 begins with "Server implementations and deploying web sites need to consider whether they are setting…". Searching for the alternative (because an implied "or not" doesn't work for this sentence) took me to the 4th paragraph of this section, and the top of page 21, which begins with "Or, whether they are setting". This won't make it past the RFC editor, but I think it should be rephrased earlier.

Section 14.1 discusses a UA behind an SSL proxy and implies that such a connection will cause warning screens (without HSTS) or hard failures. Such a deployment would be considered a wrong deployment of an SSL proxy. Administrators usually configure the UAs that are managed, and give detailed instructions to the owners of UAs that are not managed, so that the CA used by the proxy is trusted. There should be no warnings and no hard failures.

​https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter?

Section 1:

This specification also incorporates notions from [JacksonBarth2008]
in that policy is applied on an "entire-host" basis: it applies to
all TCP ports of the issuing host.

Please make it clear that all TCP ports does not mean all application
protocols, only HTTP on all ports where it might be offered (not only
the ports registered with the IANA).

Section 7.2

Does is make sense to mention that status code 308 might be
appropriate in certain circumstances? See draft-reschke-http-status-308.

Section 8.4

The HTTP-Equiv <Meta> Element Attribute is defined in the HTML
specification, so a reference would be helpful.

Section 9

The phrase "valid Unicode-encoded string-serialized domain name" seems
a bit strange, because we don't typically refer to Unicode as an
encoding scheme. See RFC 6365 regarding such terminology.

Section 11.1

I think the text about "no user recourse" conflates two things:
showing a warning, and allowing the user to click through: "the user
should not be presented with an explanatory dialog giving her the
option to proceed." Would it be OK for a user agent to show an
explanatory dialog but not provide an option to proceed? Is there a
security reason to fail the connection without any explanation?

Section 11.5

The note it worded a bit oddly (e.g., "it shouldn't be possible for an
attacker to inject script..." might be better worded along the lines
of "implementations need to guard against alowing an attacker to
inject script...").

[jeff.hodges@…]

forked two items to their own tickets...

Section 7.2

Does is make sense to mention that status code 308 might be
appropriate in certain circumstances? See draft-reschke-http-status-308.

forked to Ticket #43
​http://trac.tools.ietf.org/wg/websec/trac/ticket/43

Section 9

The phrase "valid Unicode-encoded string-serialized domain name" seems
a bit strange, because we don't typically refer to Unicode as an
encoding scheme. See RFC 6365 regarding such terminology.

forked to ticket #44
​http://trac.tools.ietf.org/wg/websec/trac/ticket/44

[jeff.hodges@…]

fixed in -07