Re: [websec] Issue #41 add parameter indicating whether to hardfail or not

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 12 June 2012 07:00 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 87F3921F8513 for <websec@ietfa.amsl.com>; Tue, 12 Jun 2012 00:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.081
X-Spam-Level:
X-Spam-Status: No, score=-98.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 kDKmLjLrjrl9 for <websec@ietfa.amsl.com>; Tue, 12 Jun 2012 00:00:45 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id A2E1C21F8512 for <websec@ietf.org>; Tue, 12 Jun 2012 00:00:45 -0700 (PDT)
Received: (qmail 24161 invoked by uid 0); 12 Jun 2012 07:00:45 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 12 Jun 2012 07:00:45 -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=QuSbn4348meQRBA+WMF75zlemHknLVSKeAp0WUNrrfo=; b=N1lrz42wuTebevURJyxFtrgpDLkKbt7tPhfTkUzI8SkW+Ym3FPAPYcOcRO27AM1U+THvw/gqCvIQSO9n0ScwycX0ZGHugf2KyyFSViML77DskUtYffb6uKrr9oilZcyM;
Received: from [24.4.122.173] (port=50809 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SeL5o-0002VV-PO; Tue, 12 Jun 2012 01:00:44 -0600
Message-ID: <4FD6E91B.2000602@KingsMountain.com>
Date: Tue, 12 Jun 2012 00:00:43 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [websec] 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: Tue, 12 Jun 2012 07:00:46 -0000

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