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

=JeffH <> Fri, 20 April 2012 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C4D321F85C5 for <>; Fri, 20 Apr 2012 10:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.937
X-Spam-Status: No, score=-99.937 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QzdLJCTyWLmL for <>; Fri, 20 Apr 2012 10:50:55 -0700 (PDT)
Received: from ( [IPv6:2605:dc00:100:2::a7]) by (Postfix) with SMTP id 41CA721F85D0 for <>; Fri, 20 Apr 2012 10:50:52 -0700 (PDT)
Received: (qmail 7913 invoked by uid 0); 20 Apr 2012 17:50:50 -0000
Received: from unknown (HELO ( by with SMTP; 20 Apr 2012 17:50:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=YMK4Vn7HLrvnF8ScbUPQjz9Z19WOcfk3kNXtKybaXPU=; b=Jk1GMUIjOa7h/CpnmYPMloDaWI97fwINUcM0HjTIjrV3hxfORUf0yaDiB1ZvM7nrw7P1is7qKxAIEeMToq/nChksNsIR2kDqzeocEGobNO/KcX1sPR/+HzWnuwdsWVpa;
Received: from ([] helo=[]) by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1SLHyr-0001oX-SL; Fri, 20 Apr 2012 11:50:49 -0600
Message-ID: <>
Date: Fri, 20 Apr 2012 10:50:48 -0700
From: =JeffH <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Paul Hoffman <>, IETF WebSec WG <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Apr 2012 17:50:56 -0000

 > #39: appropriately acknowlege and accommodate DANE

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

    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.