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

[Mike Bishop <[e-mail]>]

I support the theory behind the first change, but I must point out that there’s a substantial procedural hurdle it creates.  If you require strong certificate authentication on the alternate… this is Alt-Svc as already described in an existing Standards-track RFC.  What, precisely, is the experiment this document would describe at that point?  Why do we need an experimental RFC that effectively says “Hey, RFC 7838 – we really meant it!  Try it!”  .wk provides some interesting features we could experiment with, but you can’t require it simply because it’s not in the Alt-Svc spec.  If you’re not doing something different than Alt-Svc, anything you define is inherently an optional extension to it (or a new version).

The reason it’s currently “fuzzy” is actually very deliberate – RFC 7838 requires “reasonable assurances” that the destination is under the same control as the origin, but defines only one way to do that – certs.  Opp-Sec defines a second, the presence of .wk on both origin and alternate.  It’s optional in that you can use either – but if you don’t want to use certificate validation, then .wk is required as your only other (currently-defined) option.  I think the doc already says that, but if it’s not clear, we should make it clearer.

I agree that the commitment option in .wk conflicts with that goal a little bit – enhancing .wk to be a more generalized way to add parameters to Alt-Svc is interesting in itself.  If we have a collection of things we want to put in there, that warrant the new RFC on its own.  But you’re proposing eliminating both purposes that it currently serves, while retaining it, which is… interesting.  ☺

From: Nick Sullivan [mailto:[e-mail]]
Sent: Wednesday, September 7, 2016 10:49 AM
To: Patrick McManus <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: 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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi all - Firefox Implementer Hat on here.
Nick @cloudflare and I have been working on implementing the httpwg.org/http-extensions/opsec.html<http://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