W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

From: Peter Eckersley <pde@eff.org>
Date: Wed, 4 Feb 2015 15:14:02 -0800
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Ryan Sleevi <sleevi@google.com>, Eduardo' Vela <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>
Message-ID: <20150204231402.GF501@eff.org>
On Wed, Feb 04, 2015 at 11:20:40AM +0100, Mike West wrote:
>
> This is exactly what HSTS is for, isn't it? I'm not a huge fan of creating
> yet another pinning mechanism.

A fair point, but....
 
> Splitting into "Insecure", "Pretty Secure For Newer Clients", and "Always
> Secure Forever And Ever And Don't Let Anyone Touch It" seems like a
> division folks can wrap their heads around. Adding more flags complicates
> the model significantly.

I think I'm persuaded that (even with better sys admin tools in
the pipeline) we should avoid complicated configuration options which
exacerbate the problems developers have but obscure-but-vital aspects of TLS.

So I like your trichotomy of states, and agree with trying to design
around it.

Unfortunately, I think that does mean that both HSTS and the proposed new
CSP upgrade flag should have the overlapping effect of upgrading
navigational HTTP requests to the domains that set them.

If you're really unhappy about that overlap in functionality, WDYT about
implementing the exact same "Pretty Secure For New Clients" state as a
"Helpful" or "Easy" directive to the HSTS header, rather than a new CSP
directive?

-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
Received on Wednesday, 4 February 2015 23:14:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC