On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote: > Hi, thanks for the response. Comments inline: > > On Jul 29, 2012, at 10:29 PM, =JeffH <[email protected]> wrote: > >>> -- I did not find any guidance on how to handle UAs that do not understand >>> this extension. I don't know if this needs to be normative, but the draft >>> should at least mention the possibility and implications. >> >> Agreed. My -12 working copy now contains these new subsections.. >> >> ### >> 10. Server Implementation and Deployment Advice >> >> This section is non-normative. >> >> 10.1. Non-Conformant User Agent Considerations >> >> Non-conformant UAs ignore the Strict-Transport-Security header field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1 >> "Non-Conformant User Agent Implications" for further discussion. >> >> . >> . >> >> 14. Security Considerations >> . >> . >> 14.1. Non-Conformant User Agent Implications >> >> Non-conformant UAs ignore the Strict-Transport-Security header field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". >> >> This means that the web application and its users wielding non- >> conformant user agents will be vulnerable to both: >> >> Passive network attacks due to web site development and deployment >> bugs: For example, if the web application contains any insecure, >> non-"https", references to the web application server, and if not >> all of its cookies are flagged as "Secure", then its cookies will >> be vulnerable to passive network sniffing, and potentially >> subsequent misuse of user credentials. >> >> Active network attacks: If an attacker is able to place a man-in- >> the-middle, secure transport connection attempts will likely yield >> warnings to the user, but without HSTS Policy being enforced, the >> present common practice is to allow the user to "click-through" >> and proceed. This renders the user and possibly the web >> application open to abuse by such an attacker. >> >> This is essentially the status-quo for all web applications and their >> users in the absence of HSTS Policy. >> ### > > That's all good text, but I'm not sure it actually captures my concern. > > From the server's perspective, the fact that non-conformant UAs may exist, > the server cannot assume that UAs will honor the extension. This means that a > UA might attempt unprotected access to some resource assumed to be protected > by this extension. That is, the server can't merely select the extension and > forget about things--it still needs to to take the same care to avoid leaking > resources over unprotected connections that it would need to do if this > extension did not exist in the first place. > > I think this is implied by your last sentence above, but it would be better > to say it explicitly.
Hi Ben On this issue, it should be noted that there is never a guarantee that a UA will respect this extension: - Older UAs and the latest and greatest Internet Explorer do not support this - Any UA that has not visited this website yet may try to access insecurely - Any UA that has visited this website, but has not done so within the time period may try to access insecurely A server can use HSTS to reflect a "no HTTP" policy, but it cannot be used to enforce a "only clients that know I'm STS" policy. That is outside the scope of the draft. A DNS-based approach could solve the TOFU issue, but older clients (or those without access to the secure DNS) could always try to get things over HTTP Yoav _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
