From: Yoav Nir <ynir@checkpoint.com>
To: Ben Campbell <ben@nostrum.com>
Date: Thu, 2 Aug 2012 21:18:09 +0300
Thread-Topic: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
Thread-Index: Ac1w2yvprMHoxvR2RzOTiJG6heTTcA==
Message-ID: <C0912D8D-4DA8-4E0A-9C72-0AF917EE0F9E@checkpoint.com>
References: <50161BD5.7040901@KingsMountain.com>
 <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
In-Reply-To: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: General Area Review Team <gen-art@ietf.org>,
 IETF WebSec WG <websec@ietf.org>,
 "draft-ietf-websec-strict-transport-sec.all@tools.ietf.org"
 <draft-ietf-websec-strict-transport-sec.all@tools.ietf.org>,
 IETF Discussion List <ietf@ietf.org>
Subject: Re: [websec] Gen-ART LC Review of
 draft-ietf-websec-strict-transport-sec-11
Precedence: list

On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote:

> Hi, thanks for the response.  Comments inline:
>=20
> On Jul 29, 2012, at 10:29 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wr=
ote:
>=20
>>> -- I did not find any guidance on how to handle UAs that do not underst=
and
>>> this extension. I don't know if this needs to be normative, but the dra=
ft
>>> should at least mention the possibility and implications.
>>=20
>> Agreed. My -12 working copy now contains these new subsections..
>>=20
>> ###
>> 10.  Server Implementation and Deployment Advice
>>=20
>>  This section is non-normative.
>>=20
>> 10.1.  Non-Conformant User Agent Considerations
>>=20
>>  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.
>>=20
>>                      .
>>                      .
>>=20
>> 14.  Security Considerations
>>                      .
>>                      .
>> 14.1.  Non-Conformant User Agent Implications
>>=20
>>  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".
>>=20
>>  This means that the web application and its users wielding non-
>>  conformant user agents will be vulnerable to both:
>>=20
>>     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.
>>=20
>>     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.
>>=20
>>  This is essentially the status-quo for all web applications and their
>>  users in the absence of HSTS Policy.
>> ###
>=20
> That's all good text, but I'm not sure it actually captures my concern.
>=20
> 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 th=
at a UA might attempt unprotected access to some resource assumed to be pro=
tected by this extension. That is, the server can't merely select the exten=
sion and forget about things--it still needs to to take the same care to av=
oid leaking resources over unprotected connections that it would need to do=
 if this extension did not exist in the first place.
>=20
> I think this is implied by your last sentence above, but it would be bett=
er 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 t=
his
 - Any UA that has not visited this website yet may try to access insecurel=
y
 - Any UA that has visited this website, but has not done so within the tim=
e 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 s=
cope of the draft.

A DNS-based approach could solve the TOFU issue, but older clients (or thos=
e without access to the secure DNS) could always try to get things over HTT=
P

Yoav