[ trimming to: and cc: as I think most everyone is on websec@ ]
Hi Eric, thanks for submitting this errata.
Barry & everyone: actually, this issue is in S 14 "Security Considerations"
of RFC6797, and I think Eric is correct that that subsection "14.4. The Need
for includeSubDomains" is overlooking this detail, and hence is actually an
errata (more or less).
However, the text I'd use to correct it would be somewhat different than
Eric's proposed text (tho it'd build on it).
Overall, I think we discussed this aspect of things during our development
of HSTS and rationale/defense overall amounts to..
1. HSTS Hosts really need to declare HSTS Policy at their top-level domain
name whether or not they are reachable at other subdomains thereof and
regardless of whether they employ . I.e., it's poor practice to have an
HSTS Host at https://sub.example.com yet also answer at https://example.com
without also declaring the latter as an HSTS Host.
In terms of there being a policy authority boundary between one's HSTS Host
and it's immediate superdomain -- eg between example.com. and com. -- that
to some degree is presently addressed by language in RFC6265 section 5.3
step 5 --- but nominally I think Eric is overall correct and this "cookie
injection attack via superdomain of HSTS Host" isn't properly discussed in
RFC6797 and that it would (today) be an issue for example if foo.example.com
is a distinct entity from example.com, and example.com _is not_ a "public
suffix". Essentially, i think there's a subtle impedance mismatch between
HSTS's Storage Model and that of HTTP cookies per RFC6265, and it's arguably
a spec bug in rfc6797 that it isn't explicitly called out.
Thus Barry is correct that this is treading into "domain boundary" aka
"domain policy authority" territory <[email protected]> -- and thus is another
example of why the latter work is important (several of us, along with
Andrew Sullivan, are chipping away at it).
Also, there's a recent draft academic paper that's been mentioned on other
lists that I am going to post a reference to on this list -- it goes into
HSTS deployment common mistakes as well as best practices and touches on
issues similar to this.
ah, I see Eric's proposed best practice in his reply to Yoav, and yeah,
that's one way to address this issue, and could ostensibly be included in a
spec update -- but the actual errata is the above-noted impedance mismatch
between cookies' and HSTS's storage models (and also the lack of cookie's
declaring their originating origin).
HTH,
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
