Re: [UPGRADE] Consider plan B for reduced complexity?

On Mon, Mar 16, 2015 at 11:14 AM, Peter Eckersley <pde@eff.org> wrote:

> So to be clear, I agree that dkg's proposal (which we could call
> "upgrade-insecure-by-default") will require some kind of client ->
> server compataibility signalling mechanism.  In fact I think I said that
> here:
>
> https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0030.html


Got it.

In that case, I'd suggest that the entire difference between this proposal
and the upgrade spec can be boiled down to:

1. The things in the upgrade spec happen by default when a page is
delivered over HTTPS.
2. Separately, the HSTS2 header allows sites to lock upgradable folks into
TLS.

Is that accurate?

Probably that should be a header, "Prefer: https" is okay, "Prefer: tls"
> is even shorter :)
>

I like it!
https://github.com/w3c/webappsec/commit/29d07a99aebebd02f40a2daa9feb8425c36c5c21


> > (As an aside: I don't at all think that Daniel's proposal runs counter to
> > the UPGRADE spec. I think we can evaluate how to make aspects of that
> spec
> > default behavior in parallel to shipping it as an opt-in.)
>
> Yes, I agree that these efforts are closely aligned.
>

I'm focused on the opt-in mechanism for the moment, because I think that's
something we can ship quickly. I think a minimum-viable implementation
could go out in Chrome 43, we can get some author feedback to see if it
solves their problems in the ways we expect, and work on solving the
concerns that remain.

Does that sound like a reasonable approach from the EFF's perspective?

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)