I have been selected as the Applications Area Directorate reviewer for this draft.  (For background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

[NOTE: This is a pre-Last Call review requested by the Applications Area Directors.  Please disregard any boilerplate indicating otherwise.]

Please resolve these comments along with any other Last Call comments you may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-websec-strict-transport-sec-06
Title: HTTP Strict Transport Security (HSTS)
Reviewer: Murray S. Kucherawy
Review Date: April 28, 2012
IETF Last Call Date: n/a
IESG Telechat Date: n/a

Summary: This draft is almost ready for publication as a Standards Track RFC, but has a few issues that should be fixed before publication.

Reviewer Synopsis: The document specifies methods by which providers of web-based services can signal to users (and their web clients) that their services should only be accessed via secure mechanisms.  It also gives a detailed treatment of the threat model leading to the proposal it contains.

This is one of the more well-written drafts I've reviewed in some time.  It's clear and very complete in terms of presenting the background, which is very helpful to readers (and reviewers!) not expert in this area.

MAJOR ISSUES:

None.

MINOR ISSUES:

Section 2.3.2: Your Security Considerations section should probably include a pointer to this section.

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.

Section 4, HTTP Strict Transport Security Host: Should this say "for all web pages it serves" or similar?

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.

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.

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?

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

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

Section 14.2: The "but the attacker has established somewhere" clause doesn't parse for me.  What's it trying to say?

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.

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.

Section 1: "Section", when referring to a section of a document, should be capitalized.  (Also occurs in a few other places.)

Section 2.2: s/known as a HSTS Host/known as an HSTS Host/

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/

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.

Section 2.3.1.2: Define or expand "CA" on first use.  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?

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/

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.

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.

Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here?  Isn't it really a "Protocol"?

Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/ (so as to avoid "specified in this specification")

Section 4, "Known HSTS Host": s/a HSTS/an HSTS/; two instances

Section 4, "Local policy": Why is "configuration settings" quoted?

Section 4, "unknown HSTS Host": s/a HSTS/an HSTS/

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, so it's clear you're referring to the defined term.

Section 5, second paragraph: All-lowercase "may" should probably be "MAY".

Section 6.1.2: s/which/that/

Section 7: s/facets:/facets,/; s/the second/and the second/

Section 7.1: s/a STS header/an STS header/; two instances

Section 7.1: s/difficult to uniformly emit STS header fields/difficult to emit STS header fields uniformly/

Section 7.2, second bullet: Add a matching "--" after "components".

Section 8.1: s/a STS header/an STS header/; s/field, /field /

Section 8.1.1: s/a HSTS Host/an HSTS Host/

Section 8.1.1: s/that the host responded to/to which the host responded/

Section 8.1.1: That last paragraph is one big long sentence.  Suggest breaking it up.

Section 8.5: The "For example, ..." is a sentence fragment.

Section 9, bullet 2: Remove the "," after "label".

Section 9, bullet 2: s/latter,/latter;/

Section 9, bullet 3: The (".") should come after the hex.

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, an
d these notations are extraneous)

Section 10.1, fourth paragraph: This is another sentence fragment.

Section 10.2: s/their own/its own/ (the noun is singular, the verb has to agree)

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

Section 10.2, note: s/attack, see/attack.  See/

Section 10.3: s/implications -- for/implications.  For/

Section 10.3, second paragraph: s/which/that/

Section 10.3: s/HSTS, and that have/HSTS that have/; s/application, would/application would/

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

Section 11.1: s/Establishment"),/Establishment")/

Section 11.2: s/a HSTS Host/an HSTS Host/

Section 11.2, Note: s/basis -- see/basis.  See/

Section 11.2, Note: s/is independent of/is independent of,/

Section 11.2: Opens with a non-sentence.

Section 11.3: Opens with a non-sentence.

Section 11.4: Opens with a non-sentence.

Section 11.4, Note: s/to more clearly define the term(s)/to define the term(s) more clearly/

Section 11.5: Opens with a non-sentence.

Section 12: All lowercase MUST here.

Section 12.2: Seriously nitty here: The "host, and the port (if present)" doesn't make it clear if the separating colon is included.

Section 14.1, first bullet: Missing close parenthesis.

Section 14.1, second bullet: s/to no longer be regarded/to cease being regarded/

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/

Section 14.2: s/to adequately protect/to provide adequate protection for/

Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy manually/

Section 14.3, third "*" bullet: Contains two sentence fragments.

Section 14.3, final paragraph: s/to automatically regard/to regard automatically/

Section 14.5: Expand NTP on first use, and provide a reference.

Section 14.6: Opens with a sentence fragment.

-MSK