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

( was off-list )

Martin Thomson <>: (Wed Nov  2 17:37:55 2016)
> On 2 November 2016 at 18:39, Kari Hurtta <> 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?
> (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.

| 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.

|>         • 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.

|   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 

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 
  because existence of 
  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

Received on Wednesday, 2 November 2016 17:25:03 UTC