Re: 2.2. Interaction with "https" URIs | Re: Op-sec simplification

[Kari Hurtta <[e-mail]>]

Martin Thomson <[e-mail]>: (Fri Nov  4 02:16:35 2016)
> On 3 November 2016 at 07:02, Erik Nygren <[e-mail]> wrote:
> > An example of why this could be bad would be a CDN server that terminates
> > both HTTP and HTTPS over TLS but demuxes them such that HTTPS requires TLS
> > to content origin but HTTP is allowed to go cleartext to content origin.
> > When a single TLS connection demuxes to a mixture of TLS and cleartext
> > traffic, this feels like asking for increased trouble and attack surfaces.
> > Prohibiting mixed-scheme on the incoming connection makes this feel much
> > safer.
> 
> I am almost inclined to say that you don't get to use the feature if
> you are concerned about this causing issues of that sort.  Or, as some
> of us have discussed, a new h2 setting that prohibits coalescing might
> be a simpler option.
> 
> Kari's solution works, though it opens other possibilities, and I'm
> concerned we're off down the rabbit hole again:
> 
> { "http://...": "mixed-scheme", --> open season
>   "http://...": "single-scheme", --> only one scheme per connection
>   "http://...": "dedicated-connection" } --> only one origin per connection

Only one origin per connection ("dedicated-connection") is 
better to use some other mechanism because that look 
someting which is not limited to Opportunistic HTTP Security.
It looks like something which is wanted also for "https".

"single-scheme" looks like rougly same than "distinct-connection" 
on my suggestion.  "distinct-connection" was 'own connection for 
Opportunistic HTTP Security' and that imply that only scheme used 
on that connection is "http". 

And "Opportunistic HTTP Security" really does not want say
usage of other connections, which are not used by it, so 
"single-scheme" does not say more than "distinct-connection".

/ Kari Hurtta