Hi, thanks for the response. Comments inline:
On Jul 29, 2012, at 10:29 PM, =JeffH
<Jeff(_dot_)Hodges(_at_)kingsmountain(_dot_)com> wrote:
-- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that
should be explicitly flagged and mentioned in the abstract.
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.
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.
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.
this is something to discuss this coming week @IETF-84 Vancouver it seems.
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.
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.
-- 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?
this is in the draft. the short answer is that at policy enforcement time,
"superdomain matches win".
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".
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?
-- 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.
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.
-- 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.
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?
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.
-- section 8.4:
Does this imply a duty for compliant UAs to check for revocation one way or
another?
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?
[...]
-- 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:"
As it turns out, almost all the Notes are parenthetical.
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?
Yes, thanks.
-- section 7:
Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for
SSL3?
no, it's just that SSLv3 remains a fact of life and is referenced for
completeness' sake.
Okay.
-- 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.
[ 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. ]
yes, a congruent match is intended to apply whether or not the flag is
present.
yes, I meant 8.3. And on re-reading, I think the text is fine.
-- 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.
We can move section 12 up ahead of the non-normative guidance sections.
I think that would help, thanks.
-- 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?
yes.
Would
proxies that tunnel TLS via the CONNECT method have this issue?
I don't think so in the general case.
I'm not sure what terminology to use to differentiate such proxies if this is
a detail worth addressing.
Okay
thanks again,
=JeffH