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

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Sep 2016 13:22:28 -0400

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

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 07 Sep 2016 17:48:54 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 Sep 2016 18:30:52 +0000

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:[email-masked]]
Sent: Wednesday, September 7, 2016 10:49 AM
To: Patrick McManus <[email-masked]>; HTTP Working Group <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Sep 2016 16:12:19 -0400

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 <[email-masked]>
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:[email-masked]]
> *Sent:* Wednesday, September 7, 2016 10:49 AM
> *To:* Patrick McManus <[email-masked]>; HTTP Working Group <
> [email-masked]>
> *Subject:* Re: last call Feedback for Opportunistic Security for HTTP
> (Experimental)
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Sep 2016 10:01:03 +1000

> On 8 Sep 2016, at 4:30 AM, Mike Bishop <[email-masked]> wrote:
> 

I agree there's probably more text than necessary (and hopefully we can deforest the document a bit; there's a lot of history in there). 

However, I think *something* is necessary, since using the HTTP URI scheme over a TLS connection isn't described anywhere. You can connect the dots between HTTP, Alt-Svc and the definition of h2, but that's a pretty obscure path...
 
> 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 d…

Right. In Patrick's proposed approach, we'd be using .wk not for Reasonable Assurances in the Alt-Svc sense, but instead to ensure that the alternative has opted into being used in this manner (since it might think it was being served with the HTTPS scheme otherwise).

>  
> 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
>  
> On Wed, Sep 7, 2016 at 10:28 AM Patrick McManus <[email-masked]> wrote:
> 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.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Kari hurtta <[email-masked]>
Date: Thu, 8 Sep 2016 20:16:30 +0300 (EEST)

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0570.html

> mean it wants to see requests for http://foo.example.com there..

I did not wrote about this (I think), but I agree.

> scheme, there's nothing wrong with defining that - especially if that's

It make sense that client want see 

GET /.well-known/http-opportunistic HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Content-Type: application/json
Connection: close

{
  "http://www.example.com": {
     "lifetime": 86400
  }
}

on alternative service to indicate that this port is meant for 
http:// scheme.

Otherwise valid certificate may be just for https:// scheme.

And

GET /.well-known/http-opportunistic HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Content-Type: application/json
Connection: close

{
  "http://www.example.com": {
     "lifetime": 86400,
     "mixed-scheme": true
  }
} 

is stronger case for that.

Client may require other indications
than just these what RFC 7838
"HTTP Alternative Services" says.

Mentioning that possibility on
/.well-known/http-opportunistic
specification makes sense.

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0566.html

> 1] opportunistic security should require TLS authentication. 

I have not yet strong preference here.

If TLS authentication is required, then
seems that "tls-port" can be get rid of.

Client of course can require TLS authentication
always.

> poorly with alt-svc.

Make sense.

I also had on my last comments some notes about that lifetime
of commitment (unclear specification)

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0087.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0008.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0431.html

I also noted that "tls-commit" does not require 
/.well-known/http-opportunistic on alternative service.

https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun/0409.html

I agree to get rid of "tls-commit" for simplify.

=====

So /.well-known/http-opportunistic becomes
to check that TLS port is meant for http -scheme
(and perhaps that origin and alternative service
 both gives same /.well-known/http-opportunistic ).

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Sep 2016 12:48:52 +1000

It seems like there's support for doing this, at least to the point where we should edit the document so the WG can see what it would look like.

I'll take a crack at doing that so we can talk about it in Seoul (if not before).

Cheers,

> On 8 Sep. 2016, at 3:22 am, Patrick McManus <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Sep 2016 13:24:28 +1000

Early cut here, feedback welcome:
  http://httpwg.org/http-extensions/opsec.html

> On 28 Sep. 2016, at 12:48 pm, Mark Nottingham <[email-masked]> wrote:
>

---

From: Kari hurtta <[email-masked]>
Date: Thu, 29 Sep 2016 07:49:04 +0300 (EEST)

>   http://httpwg.org/http-extensions/opsec.html

( very quick read )

http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1

| However, it is possible that the server might become confused about whether requests’ URLs have 
| a HTTP or HTTPS scheme, for various reasons; see Section 5.4. To assure that the alternative 
| service has opted into serving HTTP URLs over TLS, clients MUST check the “http-opportunistic” 
| well-known URI defined in Section 3 before directing HTTP requests to it.

and then

5.4 Confusion Regarding Request Scheme
http://httpwg.org/http-extensions/opsec.html#confuse

and

3. The “http-opportunistic” well-known URI
http://httpwg.org/http-extensions/opsec.html#well-known

and either

2.2 Interaction with “https” URIs
http://httpwg.org/http-extensions/opsec.html#rfc.section.2.2

| Because of the risk of server confusion about individual requests’ schemes (see Section 5.4), 
| clients MUST NOT mix “https” and “http” requests on the same connection unless the 
| http-opportunistic response’s origin object Section 3 has a “mixed-scheme” member whose value 
| is “true”.

does not make clear that this “mixed-scheme” check must be done for http-opportunistic resource
returned by chosen alternative service.

After all it is chosen alternative service which can be confused about scheme.

2.1 Alternative Server Opt-In
http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1

there is

| The chosen alternative service returns the same representation as the origin did for the 
| http-opportunistic resource.

but that only apply when determining  “reasonable assurances”.

Or have I missed something?

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Sep 2016 17:14:56 +1000

Good point, I'll try to clarify.

Cheers,

> On 29 Sep. 2016, at 2:49 pm, Kari hurtta <[email-masked]> wrote:
>