appropriately acknowlege and accommodate DANE

[jeff.hodges@…]

see..

Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9 (paul hoffman)
​https://www.ietf.org/mail-archive/web/websec/current/msg01092.html

This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST-compliant browsers to fail, even if those certificates cause matching when used with TLSA.

Proposed replacements:

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 that does
chain to a trusted root or match a trusted certificate association
from the TLSA protocol [I-D.draft-ietf-dane-protocol].

. . .

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 CA certificate stores, and
if HSTS Policy is enabled on a site identifying itself using a self-
signed certificate, and the certificate presented by the TLS server
does not match a trusted certificate association from the TLSA
protocol [I-D.draft-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.
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 TLSA protocol; all
browsers that also use TLSA will then be able to trust the
self-signed certificates if it announced through TLSA.

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".

[jeff.hodges@…]

fixed in -07