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

Can we just solve this with the ORIGIN frame?
In particular, define that clients must not request with http scheme
unless an ORIGIN frame has advertised it?
What gets presented in the ORIGIN frame looks remarkably close to what
Martin listed
above as the bare-minimum version of the .wk resource that we've
effectively boiled things down to:

  [ "https://example.com", "http://other.example.com" ]
>

The primary down-side that I see is that this doesn't provide a way
to specify allowing both http and https but just not mixed over the same
connection.
(I guess we could have a flag on the ORIGIN frame for ALLOW_MIXED_SCHEME,
although this could be tricky if clients send before getting the frame.)

Pros of ORIGIN frame:
* Can be server-sends-first (unlike .wk)
* Might be possible to define that if hostname=origin and if both
https://hostname and http://hostname is sent as ORIGIN frames that both can
use the same connection even without AltSvc?  (This could potentially help
protect sites with mixed-scheme resources without needing to have anything
sent cleartext.)

Cons of ORIGIN frame:
* Requires server/protocol side changes beyond putting a file in-place
(which may be just fine)

         Erik



On Wed, Oct 5, 2016 at 8:35 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> I'll try, but it might be ELI15...
>
> On 6 October 2016 at 04:28, Mike Bishop <Michael.Bishop@microsoft.com>
> 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.
>
>