Re: Feedback on the Strict-Transport-Security specification (part 2)

This addresses the remaining items in EricLaw's feedback.

I have a -06 spec rev opened up and spread around the garage here with various
fixes & enhancements in progress...

=JeffH
------


 > Editorial &  issues [Section: Abstract] defines a mechanism to enabling Web
 > sites

fixed in -06.


 > [Section 1: Introduction] I've never seen a spec use the word annunciate
 > before. Any reason not to prefer "announce" or "display"?

Ah, well, as one who's been exposed to control systems design, it seemed a 
natural term to me (and it's used correctly in the instance you cite). I did a 
little bit of research and it's apparently a term of art in the HCI world. 
fyi/fwiw.

 > [Section 1: Introduction] or if a server's domain name appears incorrectly.
 > Isn't the problem here typically that the domain name does not appear at
 > all?



 > [Section 1 : Introduction] a HTTP request header field is used to convey
 > site policy to the UA.  This specification proposes a HTTP response header,
 > not a request header.

oops. fixed in -06.


 > [Section 2.2: Policy Summary]  terminates, without user recourse, any secure
 >  transport connection attempts upon any and all errors. I'm not convinced
 > that any and all is the right way to go here. Shouldn't this spec call out
 > each certificate and certificate chain error?  Otherwise, should I consider
 > the failure in a different protocol level (e.g. gateway or DNS hiccup) as a
 > fatal error?

Good question. What is meant here is "any and all secure transport errors".

I used "any and all" because e.g. TLS has some error alerts that aren't by 
default fatal -- i.e. its various cert errors.

I'll see about crafting some more explicit language.


 > [Section 4: Terminology] The production of the "Effective Request URI" omits
 >  the protocol scheme.  I assume this was inadvertent and that the protocol
 > scheme was meant to be included.

By "production" I'm assuming you mean "definition".  Yes, the definition in 
Section 4 for "Effective Request URI" (ERU) is vague wrt scheme, and also about 
the details of how the server would go about constructing an ERU in the case 
where the Request-line header field contains just and abs-path value, and the 
Host header field contains the authority. I was thinking that we wouldn't need 
to spec the particulars on constructing an ERU in that case in this spec. (do 
we need to?)

Also, ERU is used only in section "6.2 HTTP Request Type" where it's stipulated 
that the scheme is altered as necessary to be "https" (which could mean that's 
where the implementor has the scheme added, depending on how one's 
implementation works).


 > [Section 5.1: Syntax] The spec should probably specify whether the
 > "delta-seconds" value expected to be adjusted by the HTTP "Age" response
 > header, if present.

good question -- I'm not sure. If "Age" is present, but if age_value is small 
compared to the STS max-age value, then it won't really matter whether the 
adjustment is made.

If age_value and the STS max-age value are of similar magnitude, then it starts 
to matter, it would seem. I suppose one could have a situation where there's 
long-lived (weeks? months?) cached response messages whose STS max-age value is 
less than the cached age, and thus could still being returned to clients even 
if the origin server (say) wants to turn STS off.

In looking through draft-ietf-httpbis-p6-cache-08, it seems that if an origin 
server is expecting its responses to be served through caches, and it is using 
a STS max-age value that is of the same or similar order of magnitude as the 
value it is using for the max-age response cache directive (if any), or the 
effective expires time calculated from the STS max-age value is "near" that 
stipulated by the Expires header (if any).

I am not familiar with http cache intricacies, so would appreciate help here 
from those who are so familiar.


 > [Section 5.1 Syntax] Typo: Strict-Transport-Sec HTTP Response Header

fixed in -06.


 > [Section 6.2] I'm not sure why the spec contains the confusing terminology
 > "HTTP-over-Secure-Transport" whilst simultaneously demanding that various
 > URLs be converted to specifically "HTTPS", which would preclude the
 > flexibility allowed by the more awkward terminology?

I don't think there is a conflict here, but we could perhaps explain it better.

We want to leave the door open to having HTTP mapped onto various secure 
transports, which at this time would all be signified by the "https" scheme.

E.g. today's browsers typically offer a selection between SSLv2, v3, and TLS. 
So if one configs one's browser to use only SSLv2 (for whatever reason), then 
that's what it uses when it attempts a "load" of a URI having a "https" scheme.



 > [Section 7.3] If there are any certificate errors in a HTTPS request, you
 > better not have gotten any HTTP "header fields" back from the server; if you
 >  did, you've implemented HTTPS incorrectly.

Yep, fixed in -06.


 > [Section 9] expiry time match that for the web site's domain certificate
 >
 > I'm not sure I understand the intent of synchronizing such expiration?
 > Wouldn't you explicitly not want to synchronize expiration of STS and the
 > certificate, such that the expired certificate is properly no longer useful
 > when it expires?

Please see the discussion of "lockCA" (on public-webapps@) -- the notion of 
mapping the STS expiry time to that of the cert has many considerations, so I'm 
not offhand sure of an answer to the above. That said, yes, the material on 
"STS Policy expiration time considerations" needs lots of work, and the 
consideration you cite above may not be a good one to have in the spec without 
a fair bit of explanation (it's there as more-or-less a placeholder presently).


 > [Section 10] I was happy to see the section on vendor-configured/default STS
 >  policy.  I think this is a promising mechanism.

cool, thanks.


 > [Section 11.1] I think the discussion of DoS bears further explanation, on
 > the grounds that it doesn't describe what a "fake STS header" is and how it
 > can be set. More specifically, it doesn't mention the aspects of the
 > preceding spec that make this attack difficult to execute.

Ok, will endeavor to elaborate.


---
end

Received on Thursday, 3 December 2009 23:58:17 UTC