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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 21 March 2012 14:44 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 1DC3021F8639 for <websec@ietfa.amsl.com>; Wed, 21 Mar 2012 07:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.671
X-Spam-Level:
X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, 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 5Iwd1eyl6p1u for <websec@ietfa.amsl.com>; Wed, 21 Mar 2012 07:44:26 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 919A821F861C for <websec@ietf.org>; Wed, 21 Mar 2012 07:44:26 -0700 (PDT)
Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2LEiPri065681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <websec@ietf.org>; Wed, 21 Mar 2012 07:44:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=windows-1252
From: Paul Hoffman <paul.hoffman@vpnc.org>
X-Priority: 1
In-Reply-To: <C6475516-1D41-4510-B207-AFED1DC91840@checkpoint.com>
Date: Wed, 21 Mar 2012 07:44:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD84C9BC-A279-494B-87BF-3B3051FD602D@vpnc.org>
References: <4F66623F.9000300@gondrom.org> <C6475516-1D41-4510-B207-AFED1DC91840@checkpoint.com>
To: "websec@ietf.org WG" <websec@ietf.org>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
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: Wed, 21 Mar 2012 14:44:27 -0000

On Mar 21, 2012, at 1:56 AM, Yoav Nir wrote:

> I have said this before, and was rejected by the group, so I'll raise this one last time here. 
> Section 8.3 makes it a MUST-level requirement that any failure of the underlying secure transport. Section 11.1 clarifies that there should be no user recourse for this. This makes the cost of implementing unreasonably high, and significantly discourages trial roll-outs. Adding an HSTS header to your web site takes about 2 lines of configuration file in Apache. But doing so makes small errors like letting the certificate lapse or using links with a different FQDN cause hard failures. Both these sections do now state specifically what constitutes a failure, so it might be that the intention was not to include expirations. I think this should be clarified, but mismatched names obviously apply.
> I suggest that either we remove the no user recourse advice, or else add a "hardfail" directive. Roll out with "hardfail=no", and if people don't complain, change to "hardfail=yes"

I support this idea. As we have seen with the rollout of DNSSEC, hardfails turn into bad publicity, which then turn into delayed deployment. The browser industry experiments with different ways to alert the user or hardfail, and the addition of this option would aid those experiments.

> Section 10.3 discusses the case where the server or some subdomain also hosts CRLs or OCSP and suggests some work-around to the "all TCP" port requirement. Fetching CRLs is a different context than rendering a web page. I think the suggestions should be removed and a sentence added that says that the STS policy does not apply to fetching of revocation information by the browser. I think this would be far easier to implement.

This is a very good idea and will lead to fewer surprises. There is no need to SSL-protect CRL fetches. In fact, requiring SSL-protection on CRL fetches is impossible, since you need the CRL in order to get the CRL.

--Paul Hoffman