[websec] #40: Various editorial comments on -06

["websec issue tracker" <[e-mail]>]

#40: Various editorial comments on -06

 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...").

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…          |  sec@…
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  strict-      |    Version:
  transport-sec          |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/40>
websec <http://tools.ietf.org/websec/>