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

[Mike Bishop <[e-mail]>]

Okay, so we are basically trying to backfill a possible administrative mistake by verifying that the server processes scheme as part of origin.  So an administrator MUST BUT WE KNOW YOU WON'T only put this resource in place if their server is properly configured to handle a scheme inconsistent with the port.  After they already have to opt in by sending the Alt-Svc header on the origin in the first place.  I'm lacking confidence that this check actually assures anything except that the administrator wants it to work, and we already know that from the Alt-Svc header.

If we want to *validate* that the server is handling scheme properly, then we need to have different content at http:// and https:// and check that we get the right one over the right scheme.  If an identical resource is present on both schemes, retrieving it doesn't prove anything, and I continue to doubt that it tells us anything about administrative intent that we don't already know from the Alt-Svc header being emitted.

What if http://.../.w-k/h-o MUST exist (200) and https:// .../.w-k/h-o MUST NOT exist (404)?  If a client checks both of those things, it has actually proven scheme handling rather than just asked the server to promise.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Wednesday, October 5, 2016 5:35 PM
To: Mike Bishop <[e-mail]>
Cc: Kari Hurtta <[e-mail]>; Patrick McManus <[e-mail]>; HTTP working group mailing list <[e-mail]>
Subject: Re: SETTINGS_MIXED_SCHEME_PERMITTED | Re: I-D Action: draft-ietf-httpbis-http2-encryption-07.txt

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.