[websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not)

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 29 June 2012 12:20 UTC

Return-Path: <alexey.melnikov@isode.com>
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 5FFBF21F8712 for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 05:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.887
X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.288, 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 JZZdAr+xhbkL for <websec@ietfa.amsl.com>; Fri, 29 Jun 2012 05:20:16 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF3DD21F86FD for <websec@ietf.org>; Fri, 29 Jun 2012 05:20:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340972399; d=isode.com; s=selector; i=@isode.com; bh=fHLEuKmW+7mLSG4cCozVxhQiYsskZ9LG+2VZij/Od3k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=mAX8TxAmYo+t/sGad5d5mYFhS/YJqo9gbPEQQZYiHkix4AMFfHwiuRE9WRj/Om9j/o0/9d YEw6rEU59JgedtXx3hKX4c+jeM3TOvrRGVkKr5aunWZJvjwOgkzb9fbDo8DvCQ/tzR2uRT sT+WzZD70nBpSZYp0VCmoxfjD1ADDk8=;
Received: from [] (shiny.isode.com []) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <T-2dbgAkRHA4@waldorf.isode.com>; Fri, 29 Jun 2012 13:19:59 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4FED9D7C.6010207@isode.com>
Date: Fri, 29 Jun 2012 13:20:12 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4FD6E91B.2000602@KingsMountain.com>
In-Reply-To: <4FD6E91B.2000602@KingsMountain.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <websec@ietf.org>
Subject: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not)
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, 29 Jun 2012 12:20:17 -0000

Hi Jeff,
Sorry for even slower response.

On 12/06/2012 08:00, =JeffH wrote:
> > 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).
(Speaking as a WG participant, not as a co-chair.)

I don't think relying just on server side logs is actually a good idea. 
You are effectively limiting who is able to debug the problem, which 
sometimes can be caused by things outside of direct webserver 
administrator control. Existence of "I am testing HSTS" directive would 
allow browsers to present debug information on HSTS succeeding/failing 
in some form (browser logs, additional debug frame, etc.)

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