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

Tobias Gondrom <> Sat, 24 March 2012 18:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A2DC21F8551 for <>; Sat, 24 Mar 2012 11:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.62
X-Spam-Status: No, score=-96.62 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5oa3vr17wEtK for <>; Sat, 24 Mar 2012 11:28:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 695BE21F854F for <>; Sat, 24 Mar 2012 11:28:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=GbKnmLZsotxbBDqQu0+xbdP4hVO9OuXSO66iMDqpyeOqUhrbcNHtSRk8rotSSFAhPHN+lA/KqZAeWXPcG6QhdbyfwnCxMVJo/ruafNXj5bPTwJgnTc3jRZEjBCsNGN7g; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 17570 invoked from network); 24 Mar 2012 19:28:52 +0100
Received: from (HELO ? ( by with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2012 19:28:52 +0100
Message-ID: <>
Date: Sat, 24 Mar 2012 18:28:51 +0000
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
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: Sat, 24 Mar 2012 18:28:55 -0000

On 21/03/12 14:44, Paul Hoffman wrote:
> 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.
Agree. Personally I'm not a fan of the temporary migration switch 
"hardfail=no" solution, but I can see the benefit for the transition. 
Still it would be important that servers switch to "hardfail=yes" at 
some point....
E.g. the document should state that a server SHOULD set the directive to 
"hardfail=yes" and only for testing and migration periods MAY use 

>> 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.
Absolutely correct indeed. And also CRL are integrity protected by their 

> --Paul Hoffman
> _______________________________________________
> websec mailing list