On 8/6/11 8:27 AM, =JeffH wrote:

> ALL: now's a good time to review draft-ietf-websec-strict-transport-sec
> in detail -- as mentioned in Quebec last week, we want to get this spec
> in shape for WG LC sooner rather than later (and I believe it's pretty
> close to ready as of now). I'll be popping it back up to the top of my
> to-do list after this next week.

Thanks for the poke. I've had a chance to read the spec again. Here is
some mostly minor feedback. You can consider this an AD review. :)

SECTION 1

s/Universal Resource Identifier/Uniform Resource Identifier/

Expand "UA" on first use.

   This specification embodies and refines the approach proposed in
   [ForceHTTPS], e.g. a HTTP response header field, named "Strict-
   Transport-Security", is used to convey the site HSTS policy to the UA
   rather than a cookie.

Do you mean "i.e." instead of "e.g."? I suggest:

   This specification embodies and refines the approach proposed in
   [ForceHTTPS]; i.e. instead of using a cookie it defines and uses
   an HTTP response header field, named "Strict-Transport-Security",
   to convey the site HSTS policy to the UA.

The document is a bit unclear about the denotation of "HSTS policy".
Sometimes it refers to the site's policy and sometimes to the overall
recommendations defined in the spec.

   This specification also incorporates notions
   from [JacksonBarth2008] in that the HSTS policy is applied on an
   "entire-host" basis: it applies to all TCP ports on the host.
   Additionally, HSTS policy can be applied to the entire domain name
   subtree rooted at a given host name.  This enables HSTS to protect
   so-called "domain cookies", which are applied to all subdomains of a
   given domain.

Perhaps it would be helpful to contrast the all ports and entire subtree
principles with the same origin policy also being worked on in this WG,
with an informational reference to the appropriate spec.

SECTION 2.1

   o  Web browser user wishes to discover, or be introduced to, and/or
      utilize various web sites (some arbitrary, some known) in a secure
      fashion.

Does this specification really talk about discovery? I don't see
anything about that later in the document. Also it's not clear to me
what the spec means by "be introduced to". I suggest:

   o  Web browser user wishes to interact with various web sites (some
      arbitrary, some known) in a secure fashion.

SECTION 2.3.1.3

The term "mixed content" threw me off because it is also used in XML:

http://www.w3.org/TR/2008/REC-xml-20081126/#sec-mixed-content

Also, it might be good to consistently use and prefer the term "mixed
security context" in this specification.

SECTION 3

Please use the RFC 2119 boilerplate rather than inventing your own.

SECTION 4

Regarding the terms "Domain Name" and "Domain Name Label", I'm leery of
defining them anew and would suggest referring to the definitions in,
say, RFC 5890 (or ideally RFC 1034 and RFC 1035).

SECTION 5.1

I have yet to review the ABNF here.

SECTION 7

We have a normative reference to RFC 3490, which has been obsoleted by
RFC 5890 and friends. Why not cite the definition of A-label from
Section 2.3.2.1 of RFC 5890? To wit:

   o  An "A-label" is the ASCII-Compatible Encoding (ACE, see
      Section 2.3.2.5) form of an IDNA-valid string.  It must be a
      complete label: IDNA is defined for labels, not for parts of them
      and not for complete domain names.  This means, by definition,
      that every A-label will begin with the IDNA ACE prefix, "xn--"
      (see Section 2.3.2.5), followed by a string that is a valid output
      of the Punycode algorithm [RFC3492] and hence a maximum of 59
      ASCII characters in length.  The prefix and string together must
      conform to all requirements for a label that can be stored in the
      DNS including conformance to the rules for LDH labels
      (Section 2.3.1).  If and only if a string meeting the above
      requirements can be decoded into a U-label is it an A-label.

SECTION 7.1.1

What does it mean to "congruently match"?

SECTION 7.3

Isn't RFC 2560 the right spec for OCSP?

SECTION 7.5

I can't parse this clause:

   the UA SHOULD continue to treat the host as a Known
   HSTS Host until the max age for the knowledge that Known HSTS Host is
   reached.

SECTION 8

Once again we're normatively referencing RFC 3490 instead of IDNA2008.

SECTION 11

Is "effective request URI" defined anywhere that we can reference?

SECTION 12.2

Let's add an informational reference to RFC 4732.

Can we add some more details to the description of the denial of service
attack? IMHO it's a bit thin.

GLOBAL

There are various spelling and grammar errors, but I assume those will
be fixed along the way.

That's it for now...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/