Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

[Martin Thomson <[e-mail]>]

I'll try, but it might be ELI15...

On 6 October 2016 at 04:28, Mike Bishop <[e-mail]> wrote:
> Basically, we've simplified this greatly, and I like that.  But we've simplified it so much that I'm no longer clear what problem we have left to solve. Can someone ELI5?

A client learns that a server has a "secure" alternative.  This
implies that clients can send "not-secure" requests to a "secure"
server.

The client wants to know that this alternative understands what it
means when it sends a "not-secure" request to that server.  This is
because some "secure" servers can be confused by a "not-secure"
request. They might think that it is "secure" and do the wrong thing.

We need to find a way to ask the "secure" server if it is OK with
getting "not-secure" requests.

>   - This host is authorized to serve the content for http://example.com?  That's RFC 7838 -- we're done.

I wish.

>   - This host can serve the content for http://example.com and is smart enough not to get confused when scheme and port don't match?  Again, that's RFC 7838 ("mitigate ... by refraining from advertising alternative services for insecure schemes.").  But if you want to enable clients to double-check the origin administrators, let the alternative declare that it's scheme-aware, whether by existence of a .w-k resource or a connection setting.

It's hard to know whether a server is confused just by making regular requests.

>   - This host can serve content for both http://example.com *and* https://example.com *and* http://other.example.com on the same connection without confusing them all?  That seems to be implied by the previous one.

I think that Kari was hinting at a problem where a load balancer
terminates TLS and then routes based on the Host header alone.  The
back-end servers aren't all equally capable of distinguishing between
"secure" and "not-secure".

That suggests to me that you probably want proof positive for all
origins separately, as we discussed.

>   - This host *consents* to serve http://example.com?  Seems implicit in responding to requests.  What does anyone gain by checking before sending requests versus trying the requests and maybe getting 421s?

See above regarding confusion.  Just providing a response isn't enough.

---

Here's my concrete proposal (as I made earlier):

"""
Before using a secure alternative for an http:// origin, a client MUST
first request /.well-known/http-opportunistic at that origin.  If this
resource exists and a not-stale 2xx response is obtained, then
requests for the origin MAY be directed toward the secure alternative.
The contents of this resource do not matter.  If multiple http://
origins are coalesced onto the same connection to a secure
alternative, a client MUST obtain an http-opportunistic resource from
each origin separately.
"""

You might insist on greater proof here (a Content-Location header
field would be stronger proof, or you could mandate some format for
the response body), but I don't believe that to be necessary.  Once
the http-opportunistic resource exists, then we have proof that the
server has opted in.

This does mean that in co-hosted situations an audit is recommended to
ensure that there are no resources for which there are a) necessary
variations between https:// and http:// resources on the same path and
b) confusion might be possible.  The server operator then needs to
choose whether to disable http-opportunistic just on the affected
origins or to disable the feature entirely.