[websec] #39: appropriately acknowlege and accommodate DANE

"websec issue tracker" <trac+websec@trac.tools.ietf.org> Mon, 26 March 2012 07:03 UTC

Return-Path: <trac+websec@trac.tools.ietf.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D53021F8467 for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 00:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KRrYR7ay5nYg for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 00:02:59 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org []) by ietfa.amsl.com (Postfix) with ESMTP id B210721F842A for <websec@ietf.org>; Mon, 26 Mar 2012 00:02:59 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+websec@trac.tools.ietf.org>) id 1SC3x1-0003UB-6Y; Mon, 26 Mar 2012 03:02:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "websec issue tracker" <trac+websec@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com
X-Trac-Project: websec
Date: Mon, 26 Mar 2012 07:02:47 -0000
X-URL: http://tools.ietf.org/websec/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/39
Message-ID: <070.8c5375186013134e689ba7b15f8ec943@trac.tools.ietf.org>
X-Trac-Ticket-ID: 39
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org
X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-Message-Id: <20120326070259.B210721F842A@ietfa.amsl.com>
Resent-Date: Mon, 26 Mar 2012 00:02:59 -0700 (PDT)
Resent-From: trac+websec@trac.tools.ietf.org
Cc: websec@ietf.org
Subject: [websec] #39: appropriately acknowlege and accommodate DANE
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 07:03:00 -0000

#39: appropriately acknowlege and accommodate DANE


 Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06
 until April-9  (paul hoffman)

 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

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

 Reporter:               |      Owner:  draft-ietf-websec-strict-transport-
  jeff.hodges@…          |  sec@…
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  strict-      |    Version:
  transport-sec          |   Keywords:
 Severity:  In WG Last   |
  Call                   |

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/39>
websec <http://tools.ietf.org/websec/>