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

[Kari Hurtta <[e-mail]>]

( was off-list )

Martin Thomson <[e-mail]>: (Wed Nov  2 17:37:55 2016)
> On 2 November 2016 at 18:39, Kari Hurtta <[e-mail]> wrote:
> > Hmm. Is there requirement that authority must not serve
> > /.well-known/http-opportunistic with https -origin unless
> > http and https -origins provide identical resourses and processing ?
> 
> The draft currently doesn't say anything about the
> https://.../.well.known/http-opportunistic resource.  If the resource
> happens to say something about https origins, that's kinda
> nonsensical.  Maybe I should point that out.  Do you think that this
> would help?
> 
>   https://github.com/httpwg/http-extensions/pull/261
> 
> (To paraphrase what I added: this is "http" opportunistic, not "https"
> opportunistic.)
> 
> I mean, we could insist that the https:// resource not exist, but I
> don't think we need that on the basis that we already have a pretty
> strong signal, and it keeps things simple.

https://github.com/httpwg/http-extensions/pull/261/files/dc24113b22b545ba112ebbc707b38ef3396c9f8a?short_path=fd50b7c#diff-fd50b7c5883e57d650fa3ac7f47c12f9

| This document does not define semantics for "http-opportunistic" resources 
| on an https origin, nor does it define semantics if 
| the resource includes https origins.


That is OK, but it is mostly orthogonal about that
what I was meaning. 


https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0367.html

|>         • No concern; that check that http://{...}/.well-known/http-opportunistic
|>           succeed tells enough that there is no confusion
|
| I think that this is sufficient.
|
| The reason that I think this is OK, and the reason for removing a
| mixed-scheme flag was that the risk comes from confusion.  That
| confusion exists as soon as an http:// request is made over a TLS
| connection.
| 
|  It's not that much worse when things are mixed.  The bad examples of
| routing based on the first request are bad for many reasons.  They are
| simply cause to NOT provide the .well-known resource.

Except if .well-known resource exists also on https: -origin
then bad routing still provides .well-known resource.


https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-08#section-2.2

|   The primary purpose of this check is to provide a client with some
|   assurance that a server understands this specification and has taken
|   steps to avoid being confused about request scheme.


So strong signal is that server tells that it supports Opportunistic HTTP 
Security.

Reading http://{authority}/.well-known/http-opportunistic does not
test that there is no confusion. 

( Also it is useless for http-client to check non-existence of 
  https://{authority}/.well-known/http-opportunistic
  because existence of 
  https://{authority}/.well-known/http-opportunistic
  is OK as far op-sec is considered. )

( If http: and https: origins are identical then there is no
  bad routing; just one routing. )

Maybe that is enough.

/ Kari Hurtta