> #39: appropriately acknowlege and accommodate DANE
http://trac.tools.ietf.org/wg/websec/trac/ticket/39
fyi & comment, the text I presently have in my working copy of -07 is..
.
.
.
2.2. HTTP Strict Transport Security Policy Effects
The effects of the HTTP Strict Transport Security (HSTS) Policy, as
applied by a UA in interactions with a web resource host wielding
such policy (known as a HSTS Host), are summarized as follows:
.
.
2. The UA terminates any secure transport connection attempts upon
any and all secure transport errors or warnings, including those
caused by a web application presenting a certificate matching a
trusted certificate association as denoted via the DANE protocol
[I-D.ietf-dane-protocol], or any other form of self-signed
certificate that does not chain to a trust anchor in the UA or
operating system CA root certificate store.
.
.
.
10.2. Using HSTS in conjunction with self-signed public-key
certificates
If a web site/organization/enterprise is generating their own secure
transport public-key certificates for web sites, and that
organization's root certification authority (CA) certificate is not
typically embedded by default in browser and/or operating system CA
certificate stores, and if HSTS Policy is enabled on a host
identifying itself using a certificate signed by the organization's
CA (i.e., a "self-signed certificate"), and this certificate does not
match a trusted certificate association (as denoted via the DANE
protocol [I-D.ietf-dane-protocol]), then secure connections to that
site will fail, per the HSTS design. This is to protect against
various active attacks, as discussed above.
However, if said organization strongly wishes to employ self-signed
certificates, and their own CA in concert with HSTS, they can do so
by deploying their root CA certificate to their users' browsers or
operating system CA root certificate stores. They can also, in
addition or instead, distribute to their users' browsers the end-
entity certificate(s) for specific hosts. There are various ways in
which this can be accomplished (details are out of scope for this
specification). Once their root CA certificate is installed in the
browsers, they may employ HSTS Policy on their site(s).
Alternately, that organization can deploy the DANE protocol; all
browsers that also use DANE will then be able to trust the
certificates identified by trusted certificate associations as
denoted via DANE.
Note: Interactively distributing root CA certificates to users,
e.g., via email, and having the users install them, is
arguably training the users to be susceptible to a possible
form of phishing attack, see Section 14.6 "Bogus Root CA
Certificate Phish plus DNS Cache Poisoning Attack". Thus care
should be taken in the manner in which such certificates are
distributed and installed on users' systems and browsers.
.
.
.
---
end
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
