RE: Op-sec simplification

I think the case for TBD2 is that the client sent an "ambiguous" request -- that is, connecting over port 443 and not specifying http:// or https://, but just sending e.g. GET /resource.

The problem is, if that server is also an alternate for https://www.example.com, that's not an ambiguous request -- it's a clear request for an https:// resource.  The server can't detect that unless the https:// origin isn't supported there, in which case you're likely to get an existing error (probably 400 for our current code, but a good argument could be made for 421 again).  If the https:// origin is supported there, the client will get a response and never know it asked for (and got) the wrong thing.  The server simply can't fix a broken client, and TBD2 doesn't provide a useful mechanism because the server can't distinguish.

That makes it all the more important that clients know whether the server can support scheme-mixing *and then do it.*  Unless we want to require servers to have distinct scheme-always-required ports, I don't think this is a problem solvable server-side.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, October 31, 2016 10:54 PM
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: Mark Nottingham <mnot@mnot.net>; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: Re: Op-sec simplification

On 1 November 2016 at 16:25, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> That may be good idea. (This spec requires scheme and http/1.1 spec 
> does not allow scheme to be used. )

I have tried to capture this information in a PR:
  https://github.com/httpwg/http-extensions/pull/257


> |   | TBD1  | Scheme Not Allowed            | Section 2.2 |

We can probably avoid doing that on the basis that we have 421.

> |   | TBD2  | Scheme Required               | Section 2.1 |

The case for this seems weak.  You have to have a resource that is only available on the cleartext version of the site, and you have to use opp-sec, and the client has to be very silly.  I would prefer to use 404 here.  That is, assume that the client asked for a secure resource (https://example.com/http-only) which doesn't exist; rather than asking for the unsecured resource (http://example.com/http-only) which might.

Received on Tuesday, 1 November 2016 17:34:03 UTC