Re: [websec] WG Last Call for -strict-transport-sec-05 - COMMENTS

[Tobias Gondrom <[e-mail]>]

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 [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/websec