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