Re: last call Feedback for Opportunistic Security for HTTP (Experimental)

I support this change. Requiring certificate validation for opportunistic
security makes it more robust and simplifies the logic around retroactively
applying certificate validation to the .wk if the tls-commit is present.

Nick

On Wed, Sep 7, 2016 at 10:28 AM Patrick McManus <pmcmanus@mozilla.com>
wrote:

> Hi all - Firefox Implementer Hat on here.
>
> Nick @cloudflare and I have been working on implementing the
> httpwg.org/http-extensions/opsec.html - which is in wg last call on the
> experimental track.
>
> Based on that experimental work, I'm going to recommend a few changes to
> the document before sending to IETF LC. I'll open issues on these too when
> I get a chance.
>
> 1] opportunistic security should require TLS authentication. Any other
> approach undermines the opt-in mechanism of .wk. As the PKI market has
> matured to allow truly free and automated certs certificate availability is
> no longer the chief barrier to https, and so opportunistic security should
> feel comfortable requiring real authentication. (THERE IS NO PROPOSED
> CHANGE IN THE SECURITY MODEL - HTTP:// IS STILL HTTP:// AND NOT GRANTED
> HTTPS:// STATUS AT ALL). The biggest barrier to https:// at this point
> seems to be mixed content.
>
> 2] /.well-known/http-opportunistic should always be required. The current
> doc is actually a little fuzzy on this, I think by accident. It refers to
> this as an "additional mechanism" in addition to authentication. But .wk
> does not really play the same role - it allows the server to opt-in to
> being an alternate for specific origins on specific ports. So if we're
> going to use it - we should always use it. (This has no bearing on https://
> alt-svc, this is just about http:// as that is all this doc governs).
>
> 3] get rid of tls-commit (i.e. the latch to opp sec) as this plays very
> poorly with alt-svc. The notion of alt-svc has always been that it is a
> shortcut route (or dns name if your prefer) for the same content as
> supplied at the default origin. If for any reason you cannot get there, you
> can always go back to the default origin. All of the machinery around this
> (validating alternates, etc) can happen transparently and asynchronously in
> the background until they are ready to be used. A mechanism that requires a
> characteristic of a route (auth'd TLS) but not the route itself doesn't
> play well - its far too easy to brick your site for an extended period of
> time and really ceases to be opportunistic in any meaningful sense. If
> you're up to managing this, then you're probably up to the fight of running
> https:// and using HSTS which at least has the benefit of not bringing a
> whole second technology (alt-svc) into play.
>
> Let me know what you think.
>
> -Patrick
>
>