Re: [websec] WG Last Call for -strict-transport-sec-05 - COMMENTS

[=JeffH <[e-mail]>]

Thanks for your review Tobias.

when I say "done" or "fixed" below, I mean in a forthcoming -06 revision.

 > A few comments that would not interfere with WGLC. Mostly editorial
 > (spelling stuff), but also two technical comments at the end of this
 > email. The first technical is easy, the second technical comment may be
 > more an issue and may need adding one paragraph to specify behaviour in
 > the described case. (If it's not already there and I just missed it.)
 >
 > editorial:
 > - Section 1:
 > -- in the next version please remove the line " [ Please discuss this
 > draft on the [e-mail] mailing list [WEBSEC]. ]"

sure, will do -- tho I figured that the RFC-Editor would remove this as a 
matter of course.

 > -- in first paragraph, is the link to informative reference
 > [I-D.ietf-tls-ssl-version3] the best we can get, as it is a long expired
 > I-D?

Yes, for SSLv3, that's the canonical reference -- it never progressed further.
I've added an annotation to the reference.


 > - Section 2.4.1.1
 > -- s/3.UAs need to persistently remember web sites that signal strict
 > security policy enablement, for a web site declared time span./3.UAs
 > need to persistently remember web sites that signal strict security
 > policy enablement, for a by the web site declared time span.

hm, your suggested substitution doesn't parse well. Perhaps you meant something 
like this..

   UAs need to persistently remember web sites that signal strict
   security policy enablement, for time spans declared by the web sites.

..?


 >
 > - Section 3:
 > -- s/Note:  ..is a note to the reader.  These are points that should be
 > expressly kept in mind and/or considered./Note: This is a note to the
 > reader.  These are points that should be expressly kept in mind and/or
 > considered.

done.



 > - Section 5:
 > -- [with this one I am not 100% sure]
 > s/An HSTS Host conveys its HSTS Policy to UAs, only over secure
 > transport (e.g., TLS), via the Strict-Transport-Security HTTP response
 > header field./An HSTS Host conveys its HSTS Policy to UAs only over
 > secure transport (e.g., TLS) via the Strict-Transport-Security HTTP
 > response header field.

yes, that sentence is tortured.

I've done this..

         An HSTS Host conveys its HSTS Policy to UAs via the
         Strict-Transport-Security HTTP response header field
         over secure transport (e.g., TLS).



 > - Section 6:
 > -- s/This section defines the syntax of the new header this
 > specification introduces. It also provides a short description of the
 > function the header./This section defines the syntax of the new header
 > as introduced by this specification. It also provides a short
 > description of the function of the header.
 >
 > -- s/The Section 7 "Server Processing Model" section details/The Section
 > 7 "Server Processing Model" details
 > --s/Likewise, the Section 8 "User Agent Processing Model" section
 > details/Likewise, the Section 8 "User Agent Processing Model" details

Yes, those paragraphs could use some improvement. I've changed them to..

    This section defines the syntax of the Strict-Transport-Security HTTP
    response header field and its directives, and presents some examples.

    Section 7 "Server Processing Model" then details how hosts employ
    this header field to declare their HSTS Policy, and Section 8 "User
    Agent Processing Model" details how user agents process the header
    field and apply the HSTS Policy.


 > - Section 6.1, last paragraph:
 > -- s/Additional directives extending the the semantic functionality of
 > the/Additional directives extending the semantic functionality of the

done.


 > - Section 61.1.
 > -- s/see also Section 8.1.1 "Noting a HSTS Host", below/see also Section
 > 8.1.1 "Noting a HSTS Host" below

", above." and ", below." (i.e., including the commas) are commonly used 
stylistic constructions. They are also used without the commas. I prefer them 
with. e.g. observe their use here..

   https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style


 > - Section 8.1.2, point 1
 > -- s/and ignoring separator characters (see clause 3.1(4) of
 > [RFC3986]./and ignoring separator characters (see clause 3.1(4) of
 > [RFC3986]).

done.

 > -- what do you mean by clause 3.1(4) of RFC3986?

oops, good catch.  that was supposed to be "clause 3.1(4) of RFC3490", but 
that's now inappropriate due to its obsolescence by RFC5890 et al. I've fixed 
that sentence to be these two sentences..

                                       For each Known HSTS Host's domain
        name, the comparison is done with the query domain name label-by-
        label using an ASCII case-insensitive comparison beginning with
        the rightmost label, continuing right-to-left, and ignoring
        separator characters.  See also section 2.3.2.4. of [RFC5890].



 >
 > - Section 8.3
 > -- s/(e.g., certificate errors)/(e.g. certificate errors)

this is a matter of style. see also Chicago Manual of Style, section 5.54, as 
well as Wikipedia:Manual_of_Style.


 >
 > - Section 8.5:
 > -- s/until the max-age value for the knowledge that Known HSTS Host is
 > reached./until the max-age value for the knowledge of that Known HSTS
 > Host is reached.

done.

 > -- s/Note that the max age could be infinite for a given Known HSTS
 > Host./Note that the max-age value could be infinite for a given Known
 > HSTS Host.

done.


 >
 > - Section 12.2 title:
 > -- s/Determining the Effective Requrest URI/Determining the Effective
 > Request URI

done.


 >
 > - Section 12.2.1 title:
 > -- s/Effective Requrest URI Examples/Effective Request URI Examples

done.  (I wonder how my prior spell-check run missed these? sigh.)


 >
 > - Appendix B, last paragraph:
 > -- s/In summary, although both HSTS Policy and SOP are enforced by by
 > UAs,/In summary, although both HSTS Policy and SOP are enforced by UAs,

done.


 > And two technical COMMENTS:
 > - Section 5, paragraph 2:
 > "Receipt of this header field signals to UAs to enforce the HSTS Policy
 > for all subsequent secure transport connections made to the HSTS Host,
 > for a specified time duration."
 > Actually the UA must enforce this for all subsequent transport
 > connections be them secure or non-secure (i.e. if they are non-secure
 > the scheme MUST be changed to secure (http->https)).

good catch, thanks. fixed.


 > - it seems we have missed to specify one scenario:
 >
 > The case is the following: A UA notes a superdomain e.g. example.com as
 > a Known HSTS Host, with "includeSubDomains". Then after that the UA also
 > receives a HSTS header from subdomain foo.example.com (with or without
 > "includeSubDomains") and new max-age (longer or shorter time).
 > The point is in that case the HSTS timer of the superdomain
 > (example.com) MUST NOT be changed (extended or shortened) to the timer
 > used in the subdomain.
 >
 > In fact the UA MUST keep both timers in cache independently and if at
 > some point either one of them is removed (be due to expiry or because of
 > an update setting max-age=0), the second remaining HSTS value MUST still
 > be kept intact and applied. This is mainly to prevent that a subdomain
 > can invalidate the HSTS flag of the superdomain or make it expire and
 > vice versa.

yes, upon review, i think the language here in 8.1.2 "Known HSTS Host Domain 
Name Matching" (as well as in "Noting a HSTS Host") could stand some 
polishing/re-working.

Tho I'll reply on it in more detail in the "37: Clarify that superdomain HSTS 
flag does not update max-age of subdomain's HSTS max-age and vice versa" thread 
in the next day or so.

Unfortunately, the I-D deadline for IETF-83 is upon usin the next 45min, and I 
need to get -06 submitted.  Addressing this item will have to be in an -07 (I 
don't want to rush it here in next 30 min and mess it up further).


thanks again for the detailed review,

=JeffH