Hi, thanks again for your review of draft-ietf-websec-strict-transport-sec-06,
Murray.
I've interpreted and applied your comments [1] to -08, yielding an -09 working
copy.
In the below, "done in -09" means done in my working copy of -09 -- which I
haven't published quite yet. I'm trying to resolve the unrecognized directives
language thing being discussed on websec@ before doing so.
thanks again,
=JeffH
[1] HSTS: AppsDir Editorial comments
http://trac.tools.ietf.org/wg/websec/trac/ticket/46
> MINOR ISSUES:
>
> Section 2.3.2: Your Security Considerations section should probably include
> a pointer to this section.
very good point. done in -09.
> Section 3: Are the latter two paragraphs really necessary? I only find such
> statements useful when minimum conformance is not the same thing as full
> conformance.
It's apparently helpful for readers with a strong W3C-style spec background.
I'll leave them in.
> Section 4, HTTP Strict Transport Security Host: Should this say "for all
> web pages it serves" or similar?
That sort of detailed requirements are given in Section 7 Server Processing
Model. I'd rather keep the term definition to be high-level.
Plus, the statement isn't strictly true -- an HSTS Host doesn't have to return
the STS header field for all resources on all requests. (again see S7)
> Section 4: Expand ABNF on first use, and include a reference to RFC5234.
> (The reference could instead go in Section 6.)
>
> Section 6.1: The ABNF you have there requires a leading semi-colon. Based
> on your examples, I think instead you want:
>
> Strict-Transport-Security = "Strict-Transport-Security" ":"
> directive *( ";" [directive] )
>
> Note that this also allows:
>
> Strict-Transport-Security: foobar;;;;;;;;;;;;
>
> Is that okay?
>
> Section 6.1: What's "the STS directive extension point"?
>
> Section 6.1.1: I think the "delta-seconds" should be:
>
> delta-seconds = 1*DIGIT
> ; defined in Section 3.3.2 of [RFC2616]
>
> The angle-bracket notation you have there doesn't seem to be normal.
>
> Section 6.2: The second example isn't strictly correct because no space is
> allowed around the semi-colon in the ABNF in Section 6.1. It looks like you'll
> need to add optional whitespace at various points in the ABNF, or correct the
> example.
the above issues were discussed on list, the spec is based on RFC2616 ABNF (not
RFC5234), as well as there having been changes to aspects of the above quoted
text from -06 to -08. please refer to at least -08. thx.
> Section 8.1: The "Note:" includes stuff that should be normative, and thus
> is not appropriate for a side discussion note. It doesn't quite jive with
> how you've defined use of "Note:" as a document convention.
"Note:" removed.
done in -09.
> Section 8.2: The "Note that..." at the end threw me for a loop. How does
> what's said in 8.2 imply what's stated here? For example, what does it say
> about SMTP or FTP?
sec 8.2 (now 8.3) was heavily re-written in rev -07 -- I believe this comment
no longer applies.
> Section 10.1: This discussion got me wondering why an absolute time for
> HSTS Policy expiration isn't used instead of a delta. Perhaps that could be
> explained somewhere like Appendix A. (Yes, I know about time synchronization,
> but this text gave me pause.)
as I recall (this was early in the HSTS work), there were the time sync issues
plus the whole mess with cookies having both "expires" and "max-age" and other
non-trivial stuff such as needing to parse various date formats because server
implementors got it wrong but its incumbent on UA implementors to try to be a
lenient as possible, etc.
Without rummaging back through all those discussions, I've added this note to
Appendix A "Design Decision Notes" in -09, and hope it's sufficient...
<t>
The max-age approch of having the HSTS Host provide a simple
integer number of seconds for a cached HSTS Policy time-to-live value,
as opposed to an approach of stating an expiration time in the
future was chosen for various reasons. Amongst the reasons are
no need for clock syncronization, no need to define date and
time value syntaxes (specification simplicity), and implementation
simplicity.
</t>
> Section 10.3: "example-ca.com" is not a reserved domain name for use in
> examples. Suggest "ca.example.com" or "ca.example". Same issue with
> "example-ca-services.net".
done in -09.
> Section 14.2: The "but the attacker has established somewhere" clause
> doesn't parse for me. What's it trying to say?
clarified in -09:
"...but that the attacker has managed to register in
the DNS and point at an HTTP server under the attacker's control.."
#####
Ok, so amongst the below "NITS" comments was the "a HSTS" vs "an HSTS", as well
as "a STS" vs "an STS". I did some research (e.g. Chicago Manual of Style) and
will change 'em all to the "an" form. Those various comments are elided from
the below in a perhaps vain attempt at shortening the below.
> NITS (mostly trying to save the RFC Editor some work here):
>
> There are so many important references to [ForceHTTPS] that I think it
> might be helpful to include page or section numbers for those.
I added section #s to a couple more [ForceHTTPS] citation occurrences.
> Section 1: The Abstract uses "Web" as a proper noun, but this section
> includes uses of it that are all lowercase. I believe it should be used
> one way or the other throughout the document.
I fixed the occurrences in the abstract. done in -09.
> Section 1: "Section", when referring to a section of a document, should be
> capitalized. (Also occurs in a few other places.)
not sure what's being referred to here. "Section" is capitalized when it is
used to denote an explicit section in a cited doc. Am declining to capitalize
"section" in phrases such as "This section..."
> Section 2.2, bullet 1: s/to be/such that they are replaced by/
>
> Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/
sec 2.2 re-written in -07/-08, decline.
> Section 2.3.1.1: Define or provide a reference for what Firefox is, in case
> it's somehow not in common use at the time some future reader gets this.
s/Firefox/web browser extension/ done in -09.
> Section 2.3.1.2: Define or expand "CA" on first use.
done in -09.
> For that matter, would
> it be possible to reference something that talks about the difference between
> self-signed and CA-signed certificates, and why they get different treatment?
suggestions welcome.
> Section 2.3.1.3: Define or expand "SWF" on first use.
>
> Section 2.3.1.3: s/by injecting script/by injecting a script/
done in -09.
>
> Section 2.4.1.1, bullet 1: s/interacted with/accessed/
>
> Section 2.4.1.1, bullet 3: s/to persistently remember/to retain persistent
> data about/
>
> Section 2.4.1.1, ending Note: The last "," should be a ";", or a period
> followed by a new sentence.
done in -09.
>
> Section 4: Suggest ending terms with ":" so that you don't get things like
> how "domain name label" looks in this version of the draft.
>
> Section 4, "HTTP Strict Transport Security Host": s/policy/Policy/, so it's
> clear we're using your definition.
done in -09.
>
> Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here?
> Isn't it really a "Protocol"?
perhaps. text ?
> Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/
> (so as to avoid "specified in this specification")
done in -09.
> Section 4, "Local policy": Why is "configuration settings" quoted?
quoted no longer. done in -09.
> Section 5 and beyond: You define "HSTS Policy" and "HSTS Host" (note
> capitalization), but use "HSTS policy" and "HSTS host" in numerous places.
> Best to be consistent
agreed. thought I'd caught them all. done in -09.
> Section 5, second paragraph: All-lowercase "may" should probably be "MAY".
It's on "overview" -- those are not normative MAYs, lowercase usage is on
purpose. declined.
> Section 6.1.2: s/which/that/
I prefer which. declined.
> Section 7: s/facets:/facets,/; s/the second/and the second/
stylistic preference, declined.
> Section 7.1: s/difficult to uniformly emit STS header fields/difficult to
> emit STS header fields uniformly/
stylistic preference, declined.
> Section 7.2, second bullet: Add a matching "--" after "components".
some modest fixups made to that bulleted list. done in -09.
> Section 8.1.1: s/that the host responded to/to which the host responded/
done in -09.
> Section 8.1.1: That last paragraph is one big long sentence. Suggest
> breaking it up.
text?
> Section 8.5: The "For example, ..." is a sentence fragment.
done in -09.
> Section 9, bullet 2: Remove the "," after "label".
addressed in -07.
> Section 9, bullet 2: s/latter,/latter;/
addressed in -07.
> Section 9, bullet 3: The (".") should come after the hex.
done in -09.
> Section 10: "This section is non-normative." (cringe; I'm still of the
> opinion that a section is implicitly non-normative if it has no normative
> text in it, and these notations are extraneous)
am being purposefully painfully explicit with their usage in the two sections
where they occur. Keeping them.
> Section 10.1, fourth paragraph: This is another sentence fragment.
addressed in -07.
> Section 10.2: s/their own/its own/ (the noun is singular, the verb has to
> agree)
done in -09.
> Section 10.2, second paragraph: s/certificates, and their own/certificates
> and its own/; various other "their/they" to "its/it", because "organization"
> isn't plural
done in -09.
> Section 10.2, note: s/attack, see/attack. See/
>
> Section 10.3: s/implications -- for/implications. For/
done in -09.
> Section 10.3, second paragraph: s/which/that/
stylistic. declined.
> Section 10.3: s/HSTS, and that have/HSTS that have/; s/application,
> would/application would/
done in -09.
> Section 11: (cringe)
>
> Section 11: You variably spell it "implementors" and "implementers". I'm
> pretty sure the latter is correct, but either way, some of them are not. :-)
done in -09.
> Section 11.1: s/Establishment"),/Establishment")/
>
>
> Section 11.2, Note: s/basis -- see/basis. See/
>
> Section 11.2, Note: s/is independent of/is independent of,/
done in -09.
> Section 11.2: Opens with a non-sentence.
>
> Section 11.3: Opens with a non-sentence.
>
> Section 11.4: Opens with a non-sentence.
fixed in -07.
> Section 11.4, Note: s/to more clearly define the term(s)/to define the
> term(s) more clearly/
done in -09.
> Section 11.5: Opens with a non-sentence.
fixed in -07.
> Section 12: All lowercase MUST here.
eh? I believe the "MUST NOT" at the end of S12.2 should remain. that's the
only one.
> Section 12.2: Seriously nitty here: The "host, and the port (if present)"
> doesn't make it clear if the separating colon is included.
those are production names from the ABNF in S12.1, so I don't think it needs
addressing. If this is a problem, then you need to comment on the appropriate
draft of the httpbis suite-o-drafts (draft -p1 me thinks), too.
> Section 14.1, first bullet: Missing close parenthesis.
doh. done in -09.
> Section 14.1, second bullet: s/to no longer be regarded/to cease being
> regarded/
done in -09.
> Section 14.1: s/And even if the risk/Even if the risk/
>
> Section 14.1: s/as a HSTS Host. Thus as/as an HSTS Host. Thus, as/
>
> Section 14.1: s/But once/Once/
done in -09.
> Section 14.2: s/to adequately protect/to provide adequate protection for/
stylisticly declined.
> Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy
> manually/
stylisticly declined.
> Section 14.3, third "*" bullet: Contains two sentence fragments.
done in -09.
> Section 14.3, final paragraph: s/to automatically regard/to regard
> automatically/
stylisticly declined.
> Section 14.5: Expand NTP on first use, and provide a reference.
done in -09.
> Section 14.6: Opens with a sentence fragment.
rewrote this section in -09. please review.
---
end
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
