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

Personally I agree that there is more machinery here than is strictly
required for my tastes, but I think the arrangement I've described is
reasonable given what we're trying to accomplish.

The .wk, even absent tls-commit, brings with it a couple properties that
have been argued for here in the past. Erik (and maybe Kari? Sorry for not
looking it up) made strong cases that in the case of http:// over tls the
alternate needs a stronger opt in than TLS auth provides in order to
confirm that it is an alternate for a specific origin (including especially
the scheme). I think the concern is that if a host does indeed have a cert
for foo.example.com on port 443 (deployed to serve https) but that doesn't
mean it wants to see requests for http://foo.example.com there.. this is
thought to be a special truism even though h2 carries the scheme with every
request.. this is mostly out of concern over the historical handling of
gateways and scripts that would ignore the scheme. So .wk keeps things from
going off the rails by naming origins and alternate ports as well as opting
into the mixing of schemes on one connection.

I would honor the opinion of the server side dev on that one - from my pov
its not necessary for security, but it does improve robustness and is
simple for at least the server side to implement (by deploying .wk). I make
the claim about security because a MITM can always intercept the plaintext
http:// and send it to 443 with whatever scheme it wants - regardless of
the .wk filter it will ignore.

So there are 2 things that the .wk still accomplishes (opt in to origins
instead of hostnames and opt-in to mixed-scheme). I don't think
authentication invalidates those needs - if we do think those are
un-necessary then we don't need the doc at all - I agree. (It is somewhat
orthogonal but people have suggested other kinds of opt ins like other alpn
schemes.. but if we're going to do one I think .wk is the superior choice).

On Wed, Sep 7, 2016 at 2:30 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

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

there are all kinds of weird problems here.. like tls-commit is only valid
when you are strongly auth'd but when you are strongly auth'd the doc is
saying .wk isn't required. I guess that's not untenable - but its fragile
in practice. and the opt-in isn't in play without .wk, which I really
thought people thought was necessary. (more necessary than I think it is
personally, but I thought that was the intent of the consensus). There is
also weird interaction between lifetime, ma, and tls-commit and again the
whole opportunistic and alternate nature of the thing.. that's just very
hard to square with commit. I went down that route in implementation and my
feedback is that its easy to brick and therefore probably not something I'm
overly eager to deploy.


> 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.  J
>
>
maybe I've cleared that up? Alternatively, maybe we should focus on the
whether those opt-ins that .wk still provides are necessary.. I would
expect others to be the primary respondents in that though..

fwiw I agree that 7838 allows http over TLS with auth. But if we feel there
is a stronger way to do that with concerns that are specific to the http://
scheme, there's nothing wrong with defining that - especially if that's
what is implemented.


>
>
> *From:* Nick Sullivan [mailto:nicholas.sullivan@gmail.com]
> *Sent:* Wednesday, September 7, 2016 10:49 AM
> *To:* Patrick McManus <pmcmanus@mozilla.com>; HTTP Working Group <
> ietf-http-wg@w3.org>
> *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 <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
>
>