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

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

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AA421F8552 for <websec@ietfa.amsl.com>; Fri, 20 Apr 2012 14:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.048
X-Spam-Level:
X-Spam-Status: No, score=-100.048 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lQu1GIg2ZH8 for <websec@ietfa.amsl.com>; Fri, 20 Apr 2012 14:18:58 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 96B3B21F854D for <websec@ietf.org>; Fri, 20 Apr 2012 14:18:58 -0700 (PDT)
Received: (qmail 2629 invoked by uid 0); 20 Apr 2012 21:18:58 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 20 Apr 2012 21:18:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=hY8sCqxCtPUdxQ12rVx+p6krdeywH2jZt+sHSevnCUc=; b=66a3COr55p5fUOiQCeMkgamBvs14YTSSfIwe2mMa74LG6Xk0JutKfZjm0iBeUHU1p13+H/bskrXn41N70ztmJ+MxWkIqDS7LeWP9dpRJUq7LWEiibZqUcG4mK/lA79rS;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SLLEH-0002Cp-6q; Fri, 20 Apr 2012 15:18:57 -0600
Message-ID: <4F91D2BE.7050305@KingsMountain.com>
Date: Fri, 20 Apr 2012 14:18:54 -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
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 20 Apr 2012 21:18:59 -0000

Paul Hoffman noted:
 > On Apr 20, 2012, at 10:50 AM, =JeffH wrote:
 >
 >> > #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.
 >
 > I don't think this is what you meant. It sounds like that using DANE is 
considered a transport error or warning. Proposed fix:
 >
 >    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 self-signed certificates
 >        that do not chain to a trust anchor in the UA or operating system
 >        CA root certificate store, except when the self-signed certificate
 >        is part of a validated certificate association as defined in
 >        [I-D.ietf-dane-protocol].


thanks.

hm...

In looking at this section, which is attempting to only (non-normatively) 
summarize the effects of the HSTS policy, it occurs to me it should be 
streamlined down to..


    2.  The UA terminates any secure transport connection attempts upon
        any and all secure transport errors or warnings.


..because section 10.2 now addresses details wrt "self-signed certs" and such.


Section 2.2 in my working copy is now..

###
2.2.  HTTP Strict Transport Security Policy Effects

    The effects of the HTTP Strict Transport Security (HSTS) Policy, as
    applied by a conformant UA in interactions with a web resource host
    wielding such policy (known as a HSTS Host), are summarized as
    follows:

    1.  UAs transform insecure URI references to a HSTS Host into secure
        URI references before dereferencing them.

    2.  The UA terminates any secure transport connection attempts upon
        any and all secure transport errors or warnings.
###


=JeffH