[websec] Comments on "I am testing HSTS"-directive and Issue #41 add parameter "hardfail=no"?

Tobias Gondrom <tobias.gondrom@gondrom.org> Mon, 18 June 2012 18:01 UTC

Return-Path: <tobias.gondrom@gondrom.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 AE1FB21F86E5 for <websec@ietfa.amsl.com>; Mon, 18 Jun 2012 11:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.153
X-Spam-Status: No, score=-101.153 tagged_above=-999 required=5 tests=[AWL=-2.375, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, GB_I_INVITATION=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id H114c4BxM24D for <websec@ietfa.amsl.com>; Mon, 18 Jun 2012 11:01:33 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org []) by ietfa.amsl.com (Postfix) with ESMTP id 80ED821F86EB for <websec@ietf.org>; Mon, 18 Jun 2012 11:01:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=dDz3iayGazq7VGTkk7MQkyhwxKDpL5uQ71VPxIEzWEg0fsGkxHAPluDWMyehdjMH5FbMuxPQ2i4Ate38umLr+0xWXZjX/VxKPSwy5zY/bbss75lgTFkMX+9xgBghkk0e; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 23562 invoked from network); 18 Jun 2012 20:01:31 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ? ( by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jun 2012 20:01:31 +0200
Message-ID: <4FDF6CFA.3090705@gondrom.org>
Date: Mon, 18 Jun 2012 19:01:30 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: websec@ietf.org
X-Priority: 2 (High)
References: <4FD6E91B.2000602@KingsMountain.com>
In-Reply-To: <4FD6E91B.2000602@KingsMountain.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [websec] Comments on "I am testing HSTS"-directive and Issue #41 add parameter "hardfail=no"?
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: Mon, 18 Jun 2012 18:01:33 -0000

Hello all,

<hat="WG chair">

I would like to ask for feedback/opinions from the WG on this draft 
regarding the following open issue:

- in Paris we had a discussion about whether HSTS header should specify 
a "I am testing HSTS" directive. There was some support for this in the 
room but no consensus.
I would like to make a final invitation for comments/views/opinions on this?

- And as this is somehow related:
the still open #41: should HSTS have an option like "hardfail=no"?
Our meeting discussion in Paris did not show consensus in support of this.

and just in case anyone wants to read up on our meeting minutes from Paris:

Best regards, Tobias


On 12/06/12 08:00, =JeffH wrote:
> Hi, thanks for your thoughts Yoav, apologies for latency,
> > I guess my issue with this..
> ..where "this" is denying the user the capability to "click-through" 
> TLS/SSL errors/warnings in all error cases..
> > ..is because when I read the draft for the first
> > time, I thought this would be a good idea for websites that only do 
> HTTPS and
> > do not do HTTP except to redirect to HTTPS. I thought it would allow 
> them to
> > signal this information, and allow them to defeat HTTP-based MiTM 
> attacks.
> Yes, that is exactly the benefit the spec provides.
> > The
> > draft as it stands is not a good fit for this use case, because it 
> requires
> > more of the administrator than is currently reasonable to expect.
> If an admin is uncertain about their keeping their TLS/SSL certificate 
> deployment up-to-date, then they shouldn't declare themselves as an 
> HSTS Host.
> And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded 
> list, nor the upcoming Firefox one.
> > I could propose an "HSTS-light" header for this use case, but I 
> don't think
> > anybody would like to have that.
> Yeah, I'm not sure that's necessary, because what we're talking about 
> here really is whether the user is offered obvious recourse to proceed 
> with loading the web app in the face of TLS/SSL errors -- i.e., to be 
> allowed to "click through" -- and in most (all?) browsers, the user is 
> allowed to recourse to click through many TLS/SSL errors. So in some 
> sense it is the status quo for a plain old non-HSTS web app.
> In the Paris WG session, the discussion of the above morphed to 
> thinking about having a new "this site is testing HSTS" directive.
> In thinking about this, we don't think it is really necessary because 
> if one declares one's web app as being HSTS, one can watch server logs 
> to see if any requests come in over plain http, and then go track 
> those issues down. You don't really need the user agent's help to 
> figure out what is happening. It's just going to mechanically 
> transform all http URIs pointing to your site into https ones, and try 
> to load them, and if they 404, you'll know it (via your logs).
> It's arguably different with Content Security Policy (CSP) -- which is 
> where the discussed notion came from ("report-only") -- because in 
> CSP, the user agent is enforcing policy on loaded content within 
> itself and there may be no other way to figure out what it's doing.
> HTH,
> =JeffH
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec