Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

[Yoav Nir <[e-mail]>]

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 <[e-mail]> 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