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

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 12 June 2012 07:00 UTC

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
Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not
Precedence: list

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

Re: [websec] Issue #41 add parameter indicating w… =JeffH
[websec] Comments on "I am testing HSTS"-directiv… Tobias Gondrom
[websec] "This site is testing HSTS" directive (w… Alexey Melnikov
Re: [websec] Issue #41 add parameter indicating w… Eric Rescorla
Re: [websec] Issue #41 add parameter indicating w… Steingruebl, Andy
Re: [websec] Issue #41 add parameter indicating w… Alexey Melnikov
Re: [websec] Issue #41 add parameter indicating w… Steingruebl, Andy
Re: [websec] Issue #41 add parameter indicating w… Eric Rescorla
Re: [websec] Issue #41 add parameter indicating w… Alexey Melnikov
Re: [websec] Issue #41 add parameter indicating w… Adam Barth