Hi,
I believe I've made requite changes to draft-ietf-websec-strict-transport-sec
per this thread as well as the WG f2f discussion @IETF-84 Vancouver and also my
f2f discussion with Ben after the websec wg meeting.
In the below I'm just going to try to identify the individual issues from Ben's
review without quoting all the thread discussion, but also highlight the changes
I have queued in my -12 working copy of draft-ietf-websec-strict-transport-sec.
If the below looks nominally OK I can submit my -12 working copy, please let me
know (Alexey/Barry). (note: I'm going to be mostly offline for the next several
days)
thanks,
=JeffH
------
Ben's "minor items":
M1) update 2818 ?
>> -- Does this draft update any other RFCs (e.g. 2616 or 2818)?
Maybe 2818, but based on the informational status of 2818, websec wg
discussions, and discussions with Ben and EKR, there's no statement of updating
2818 in my -12 working copy.
M2) non-conformant UAs ?
>>> -- 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..
>>
>> <snip/>
>>
> That's all good text, but I'm not sure it actually captures my concern.
>
> <snip/> 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.
I've added text to my -12 working copy, it now states...
###
14.1. Non-Conformant User Agent Implications
Non-conformant user agents 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 UAs will be vulnerable to both:
o 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.
o Active network attacks:
For example, 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. Since web application providers
typically do not control the type or version of UAs their web
applications interact with, the implication is that HSTS Host
deployers must generally exercise the same level of care to avoid web
site development and deployment bugs (see Section 2.3.1.3) as they
would if they were not asserting HSTS Policy.
###
M3) the superdomain match wins (?) question (section 8.x generally)
>>> -- 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.
In our f2f discussion, Ben and I agreed that we need to clear that we stop on
first match when doing policy enforcement -- but it turns out to be not quite
that simple, due to the includeSubDomains semantics. Here's the relvant text now
in my -12 working copy, the alterations are in step 5...
###
8.3. URI Loading and Port Mapping
Whenever the UA prepares to "load", also known as "dereference", any
"http" URI [RFC3986] (including when following HTTP redirects
[RFC2616]), the UA MUST first determine whether a domain name is
given in the URI and whether it matches a Known HSTS Host, using
these steps:
.
.
4. Otherwise, the substring is a given domain name, which MUST be
matched against the UA's Known HSTS Hosts using the procedure in
Section 8.2 "Known HSTS Host Domain Name Matching".
5. If when performing doman name matching, any superdomain match
with an asserted includeSubDomains flag is found, or, if no
superdomain matches with asserted includeSubDomains flags are
found and a congruent match is found (with or without an asserted
includeSubDomains flag), then before proceeding with the load:
.
.
###
M4) section 6.1: handling header field extensibility
[ see separate message entitled "handling STS header field extendability" ]
section 7.2 must not serve insecure content?
M5) section 7.2: state explicitly must not serve insecure content?
no changes necessary, see relevant discussion in this thread.
M6) section 8.4:formal duty for revocation checking ?
Based on f2f discussions with Ben and EKR, I now have the following text in my
-12 working copy, and have moved the references to RFC2560 & RFC5280 to
Informational. The rationale is that revocation checking is not required by the
TLS and PKIX specs, they just say "here's how you can do it", and there's not
really an appropriate spec to point at (which would have any chance at all to be
actually adhered to by UAs due to the rapidly evolving nature of our
understanding of the efficacy and performance and utility of "classical"
revocation checking).
###
8.4. Errors in Secure Transport Establishment
When connecting to a Known HSTS Host, the UA MUST terminate the
connection (see also Section 12 "User Agent Implementation Advice")
if there are any errors, whether "warning" or "fatal" or any other
error level, with the underlying secure transport. For example, this
includes any errors found in certificate validity checking UAs employ
such as via Certificate Revocation Lists (CRL) [RFC5280], or via the
Online Certificate Status Protocol (OCSP) [RFC2560].
###
Ben's editorial items:
E1) Unused Reference: 'RFC6376' -- done in -12
E2) fixup indented "Note:" such that one(s) that are normative as a regular
paragraph(s) and leave the others as-is -- done in -12
E3) reference to SSLv3, ref 6101 informatively -- done in -12
E4) section 8.3 congruent match -- text is fine, no changes necessary
E5) move section 12 up ahead of the non-normative guidance sections
-- done in -12
E6) proxy sec cons apply to CONNECT proxy ? -- done in -12
( noted that the type of proxy of concern is a "MITM non-transparent proxy",
which ought to clarify that it's not a transparent HTTP CONNECT-based
proxy. (I couldn't find any dominating terminology describing these
beasts, it is all over the map, but maybe I'm missing something) )
---
end