Hi, apologies for latency. I was trying to get this reply and a -03 rev of the
spec out the door last week, but some recent events have pushed that down my
stack.
I haven't yet submitted the -03 draft, will try to do that early-to-mid next
week. it may not address absolutely everything below, as I've noted.
anyway, am issuing this reply in order to spark any discussion you may wish to
have on any of these items and as a headsup that progress is being made.
thanks
=JeffH
StPeter held forth..
>
> 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.
Thanks for the review Peter.
> You can consider this an AD review. :)
cool.
> SECTION 1
>
> s/Universal Resource Identifier/Uniform Resource Identifier/
doh. thanks.
> Expand "UA" on first use.
it already is expanded in the first para of the Introduction.
> 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.
done in my working copy.
> 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.
Have not yet addressed this item. will either do in present working copy or in
next one.
> 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.
done in my working copy.
> 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
LOL -- was unaware of that, thx for reference.
> Also, it might be good to consistently use and prefer the term "mixed
> security context" in this specification.
So this term "mixed content" has (unfortunately) been used in the web security
world since at least as early as IE6's release and perhaps (much?) earlier. The
immediate audience of this spec is going to understand the "mixed content"
term as used in that section, and wouldn't at first understand "mixed security
context". That's why I'm equating them in this spec and will try to promulgate
"mixed security context" (or something else if someone has a better idea) going
forward in general). But I don't expect the web security usage of "mixed
content" to go away -- its just too deeply embedded, unfortunately.
> SECTION 3
>
> Please use the RFC 2119 boilerplate rather than inventing your own.
done in my working copy.
> 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).
i'm going to leave that in the draft for now. they are listed there with
approrpriate references to RFC 1034 and RFC 1035 et al for
completeness/disambiguation/convenience. referencing RFC 5890 would be
incorrect thing for these terms IMV.
> 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.
I've been recently discussing aspects of the above (with you, Pete Resnick, and
others) and the more broad issues with how to properly describe "host name
canonicalization".
for now I've placed into my working copy essentially the same approach as that
we recently did in RFC6265 HTTP State Management (cookies). i understand that
we may want to enhance/modify this approach going forward, but this is a step
in that direction for now.
> SECTION 7.1.1
>
> What does it mean to "congruently match"?
It's defined in S 7.1.2.
> SECTION 7.3
>
> Isn't RFC 2560 the right spec for OCSP?
yes, fixed in my working copy.
> 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.
fixed in my working copy.
> SECTION 8
>
> Once again we're normatively referencing RFC 3490 instead of IDNA2008.
fixed in my working copy.
> SECTION 11
>
> Is "effective request URI" defined anywhere that we can reference?
well, it was originally defined in this here spec :)
it will be defined in the new HTTPbis specs once they are finalized, but we
wanted to decouple the HSTS spec from that scheduling dependency. Thus we
are retaining the definition here, but have incorporated the refinements to the
definition made by Julian.
> 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.
Have not yet addressed this item. will either do in present working copy or in
next one.
> GLOBAL
>
> There are various spelling and grammar errors, but I assume those will
> be fixed along the way.
indeed, yes. :)
---
end
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
