Hi Jeff,
thank you very much for posting the update.
I like the new version and think we are getting close.
<hat="individual">
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 [email protected] mailing list [WEBSEC]. ]"
-- 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?
- 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.
- 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.
- 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.
- 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
- Section 6.1, last paragraph:
-- s/Additional directives extending the the semantic functionality of
the/Additional directives extending the semantic functionality of the
- 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
- 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]).
-- what do you mean by clause 3.1(4) of RFC3986?
- Section 8.3
-- s/(e.g., certificate errors)/(e.g. certificate errors)
- 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.
-- 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.
- Section 12.2 title:
-- s/Determining the Effective Requrest URI/Determining the Effective
Request URI
- Section 12.2.1 title:
-- s/Effective Requrest URI Examples/Effective Request URI Examples
- 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,
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)).
- 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.
Best regards, Tobias
On 09/03/12 21:37, =JeffH wrote:
As far as I know, draft-ietf-websec-strict-transport-sec-05 is ready
for WG Last Call.
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
