Re: [websec] #39: appropriately acknowlege and accommodate DANE

=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 20 April 2012 17:50 UTC

Message-ID: <4F91A1F8.4090501@KingsMountain.com>
Date: Fri, 20 Apr 2012 10:50:48 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>, IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE
Precedence: list

 > #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] #39: appropriately acknowlege and accomm… websec issue tracker
Re: [websec] #39: appropriately acknowlege and ac… =JeffH
Re: [websec] #39: appropriately acknowlege and ac… Paul Hoffman
Re: [websec] #39: appropriately acknowlege and ac… =JeffH
Re: [websec] #39: appropriately acknowlege and ac… Paul Hoffman
Re: [websec] #39: appropriately acknowlege and ac… websec issue tracker