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

[Mike Bishop <[e-mail]>]

I'm having trouble envisioning the scenario where you need to split this by origin, though.  Our concerns here are about server implementations that ignore the scheme component and simply rely on the incoming port to provide that information, right?.  That means you need to get that information on a port-by-port (i.e. server/connection) basis.  Is there a scenario where alternate.example.com:443 is capable of parsing mixed-scheme requests for one origin, but blind to it for another?  Here are the cases I can think of:

  - Actual server with multiple origins:  It may or may not be configured to *serve* http:// scheme for all origins from that port, but that's indicated by the Alt-Svc headers pointing to it.  Mistaken requests would get a 421.
  - TLS-terminating load balancer:  The connection inside TLS will still reach a single back-end server, so see previous item.
  - HTTP reverse proxy:  The sites behind it may indeed have different capabilities, but that's strictly a function of how the reverse proxy obtains the resources, not something the client needs to validate.

As for moving forward with this, I think it depends on just what we're trying to validate.  Let's agree on the question before we argue about the answer.  Is it:

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

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?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Kari Hurtta
Sent: Wednesday, October 5, 2016 9:17 AM
To: Martin Thomson <[e-mail]>
Cc: Kari Hurtta <[e-mail]>; Patrick McManus <[e-mail]>; Mike Bishop <[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

Martin Thomson <[e-mail]>: (Wed Oct  5 17:07:16 2016)
> On 6 October 2016 at 00:36, Kari Hurtta <[e-mail]> wrote:
> >> >> "tls-ports"  should perhaps now be "mixed-scheme-listeners"
> >> >> giving [ "alternative-server:port" ].
> >
> > because should we really say that particular alternative server / 
> > port combination for given origin supports http: -scheme over TLS.
> 
> I interpreted that as:
> 
>   { "http://example.com": {
>       "mixed-scheme-listeners": [ "example.net:767", "example.com:3324" ]
>     },
>     "http://other.example.com" { ... }
>   }

Yes.
 
> This is saying that "http://example.com" is served (in addition to the 
> cleartext version) on those alternatives.

Or actually:

	If Alt-Svc -header field gives this alternative, then
	this alternative (for that origin) is safe to use
	for http: -scheme via TLS (assuming that thhis
	alternative service returns same /.well-known/http-opportunistic
	responce that origin).

〔removed 〕

> > But also for particular origin there may be several alternative 
> > servers which are not equal.
> 
> Not sure that I follow: are you suggesting that the .wk resource would 
> advertise the other origins, or that we need some sort of additional 
> protection?

/.well-known/http-opportunistic list there origins which share same /.well-known/http-opportunistic -file or resource.

For particular origin /.well-known/http-opportunistic list these potential alternatice service name and port, which are safe for
http: -scheme over TLS.

This is additional protection.  SETTINGS_MIXED_SCHEME_PERMITTED take account that all alternatice services for given origin are not good for http: -scheme over TLS, but it does not take account that connection is shared with several origins.

If /.well-known/http-opportunistic list only origins, then it does not take account that all alternative services are not hood for http: -scheme over TLS.

( I assume that alternative services are good for
  https: -scheme and they are valid certificate
  and some subset of url -path namespace is
  shared between http: and https: -scheme. 
  But /login is not good for http: -scheme.
)

/ Kari Hurtta