Re: fyi: Strict Transport Security specification

Hodges, Jeff wrote on 9/18/2009 3:21 PM: 
> We wish to bring the following draft specification to your attention..
> 
>    Strict Transport Security (STS)
> <http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html>
[...snip...]
> We're looking forward to the WebApps WG's feedback and comments.

I responded to an announcement on the WASC list[3], but am posting it again here as I was told this was the relevant forum to do so.

Andy Steingruebl wrote on 11/6/2009 1:53 PM: 
> > 2. We've launched with a very small max-age parameter for testing
> > purposes.  We expect that after more extensive testing we will deploy
> > with a much larger max-age value to provide more robust protection for
> > users.

What max-age value does PayPal expect to use in the future once your testing is complete?  I'm curious if there's a recommended value, or if it varies depending on the risk-model of the site.  Since the specification allows the value to be updated in subsequent headers, is there any downside to making it very large (e.g. 10 years)?  Even if the site's certificate expires or is revoked, couldn't the site then immediately expire STS if they want users to be able to still use the site (foolish, but it happens[1])?  Oh, that wouldn't work because STS headers are only sent over HTTPS, and if STS prevents loading a site with a problematic cert, the site wouldn't be able to communicate a different expiration.  Now I understand the note in the specification about considering expiring STS to coincide with the expiration of the cert.  In the case where a cert has been revoked, the site's only choice would be to quickly replace the existing revoked cert with a new one (which they shoul

d anyhow).  It may be worthwhile to more explicitly call out these issues in the specification, or perhaps a separate implementation considerations document.

Thinking more about immediately expiring STS, what is the STS behavior when max-age is set to 0 or a negative number?  Is it immediately disabled, or disabled on subsequent visits to the site?

Is there a maximum number of cached entries for known STS servers?  If so, might an attacker with a large number of domains be able to facilitate a 'STS eviction' attack?  If not, might an attacker be able to fill the cache with lots of bogus entries, either causing a performance issue when looking up legitimate sites or perhaps consuming large quantity of drive space?

What happens where there is more than one STS header?  Which one prevails?

Is the STS header sent on every response (e.g. responses for html, images, css, etc)?  Or just for html?

How does the server identify the STS clients?  If there isn't a way (which I don't believe there is), then given the STS requirement that a server should redirect from non-HTTPS to HTTPS, what does that mean for UAs that don't understand STS -- does the best practice of not redirecting to HTTPS still apply[2]?

- Bil


[1] American Express used revoked site certificate for weeks
    http://my.opera.com/yngve/blog/2009/10/01/american-express-used-revoked-site-certificate-for-weeks

[2] OWASP: Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Page
    http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Perform_Redirects_from_Non-TLS_Page_to_TLS_Login_Page

[3] http://www.webappsec.org/lists/websecurity/archive/2009-11/msg00005.html

Received on Monday, 9 November 2009 05:42:49 UTC