Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <50161BD5.7040901@KingsMountain.com>
Date: Thu, 2 Aug 2012 10:46:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
References: <50161BD5.7040901@KingsMountain.com>
To: =JeffH <Jeff.Hodges@kingsmountain.com>
Received-SPF: pass (nostrum.com: 130.129.98.91 is authenticated by a trusted
 mechanism)
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,
 IETF Discussion List <ietf@ietf.org>
Subject: Re: [websec] Gen-ART LC Review of
 draft-ietf-websec-strict-transport-sec-11
Precedence: list

Hi, thanks for the response.  Comments inline:

On Jul 29, 2012, at 10:29 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> =
wrote:
>=20
> > -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, =
that
> > should be explicitly flagged and mentioned in the abstract.
>=20
> Good question, I don't believe we've discussed this possibility =
directly in the websec wg. In looking at the RFCs that do update =
RFC2616, it doesn't look like draft-ietf-websec-strict-transport-sec =
(HSTS) is of that ilk.
>=20
> However, it nominally appears that an argument could be made that it'd =
be appropriate to update RFC2818 via =
draft-ietf-websec-strict-transport-sec, specifically with regards to =
Section 2.1.  Connection Initiation.
>=20
> Though, RFC2818 is Informational, which may be an issue (?). Also, =
perhaps this is something to more appropriately do via a standards-track =
rfc2818bis, i.e., have the latter reference the HSTS spec.
>=20
> this is something to discuss this coming week @IETF-84 Vancouver it =
seems.
>=20
>=20

I will comment on this in response to your post-meeting email.


> > -- 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.
>=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.
> ###

That's all good text, but I'm not sure it actually captures my concern.

=46rom 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.


>=20
> >
> > -- How should a UA handle potential conflicts between a the policy =
record
> > that includes the includeSubdomain, and any records for subdomains =
that might
> > have different parameters?
>=20
> this is in the draft. the short answer is that at policy enforcement =
time, "superdomain matches win".
>=20
> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) =
is noted regardless of whether there are superdomain HSTS hosts =
asserting "includeSubDomains".
>=20
> perhaps this needs to be made more clear?

Maybe I'm missing something, but I'm not getting that answer from the =
text. Can you point out the specific language?

>=20
>=20
> >
> > -- section 6.1:
> >
> > The draft mentions that directives may be extended, but defers =
creation of an
> > IANA registry to the time of first extension. IANA registries are =
not
> > expensive; I suggest it be created now. If there's a good reason not =
to, then
> > the draft should still address the specification policy for =
extensions.
> >
> > Also, do you expect that some future directive might need to have a
> > "required-to-understand" status? Given that this is a =
security-affecting
> > extension, it seems likely. If so, then the mechanism for expressing =
that
> > needs to be defined in this draft.
>=20
>=20
> These are good questions, and they beg the overall question of how =
complex this simple solution really needs to be and whether we really =
think we'll need any extensions. Something for us to discuss in the =
working group meeting on Tue morning I think.

I will comment on this in the post-meeting mail.

>=20
> >
> > -- section 7.2:
> >
> > Am I correct to assume that the server must never just serve the =
content over
> > a non-secure connection? If so, it would be helpful to mention that, =
maybe
> > even normatively.
>=20
> It's a SHOULD, see the Note in that section, so it's already =
effectively stated normatively, though one needs to understand HTTP =
workings to realize it in the way you stated it above.  Perhaps could =
add a simple statement as you suggest to the intro para for section 7 =
Server Processing Model, to address this concern?
>=20

I think something of the form SHOULD redirect to HTTPS, but MUST NOT =
under any circumstances send the content unprotected would improve the =
text. That's probably already implied, and a reasonable implementor =
wouldn't due it anyway. But my experience is that some readers will find =
strange interpretations whenever you give them the wiggle room to do so, =
so it's better to be explicit.

>=20
> >
> > -- section 8.4:
> >
> > Does this imply a duty for compliant UAs to check for revocation one =
way or
> > another?
>=20
> yes. though, per other relevant specifications, as duly cited. AFAIK =
the HSTS spec doesn't need to get into the details because the =
underlying security transport specs, namely TLS, already do this.

If that duty already exists, then I see no reason to add it here. But do =
the cited specs unambiguously _require_ revocation checks? I admit to =
not being an expert here, but on a quick scan it seems more like they =
say how you can do it, but do they say you have to?=20

[...]

>=20
> > -- section 1.2:
> >
> > The description of indented notes is almost precisely the opposite =
of how
> > they are described in the RFC editor's style guide. It describes =
them as
> > "parenthetical" notes, which is how experienced RFC readers are =
likely to
> > perceive them. While it doesn't say so explicitly, I think putting =
normative
> > text in parenthetical notes should be avoided. If these are intended =
to be
> > taken more strongly than that (and by the description, I take it =
they should
> > be taken more strongly than the surrounding text), then I suggest =
choosing a
> > stronger prefix than "NOTE:"
>=20
> As it turns out, almost all the Notes are parenthetical.
>=20
> I'll render the one(s) that are normative as a regular paragraph(s) =
and leave the others as-is. Will that address your concern?
>=20

Yes, thanks.

>=20
> >
> > -- section 7:
> >
> > Does the reference to I-D.ietf-tls-ssl-version3 indicate a =
requirement for
> > SSL3?
>=20
> no, it's just that SSLv3 remains a fact of life and is referenced for =
completeness' sake.
>=20
>=20

Okay.

>=20
> >
> > -- section 8.2, paragraph 5 (first non-numbered paragraph after =
numbered
> > list)
> >
> > To be pedantic, this could be taken to mean a congruent match only =
applies if
> > the includeSubdomains flag is not present. I assume it's intended to =
apply
> > whether or not the flag is present.
>=20
> [ I am assuming you actually are referring to section 8.3, as section =
8.2 doesn't mention the includeSubdomains flag and does not contain a =
numbered list. ]
>=20
> yes, a congruent match is intended to apply whether or not the flag is =
present.
>=20
>=20

yes, I meant 8.3. And on re-reading, I think the text is fine.

>=20
> > -- section 12 and subsections:
> >
> > I was surprised to see more apparently normative material after the
> > non-normative guidance sections. I think it would improve the =
organization to
> > put this closer to the normative rules for UAs.
>=20
> We can move section 12 up ahead of the non-normative guidance =
sections.

I think that would help, thanks.

>=20
>=20
> >
> > -- section 14.1, 4th paragraph (first non-bulleted paragraph =
following bullet
> > list)
> >
> > This issue is only true for proxies that act as a TLS MiTM, right?
>=20
> yes.
>=20
>=20
> > Would
> > proxies that tunnel TLS via the CONNECT method have this issue?
>=20
> I don't think so in the general case.
>=20
> I'm not sure what terminology to use to differentiate such proxies if =
this is a detail worth addressing.
>=20

Okay

>=20
> thanks again,
>=20
> =3DJeffH
>=20
>=20
>=20
>=20
>=20
>=20