Re: last call Feedback for Opportunistic Security for HTTP (Experimental)

[Kari hurtta <[e-mail]>]

> Early cut here, feedback welcome:
>   http://httpwg.org/http-extensions/opsec.html


( very quick read )

http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1

| However, it is possible that the server might become confused about whether requests’ URLs have 
| a HTTP or HTTPS scheme, for various reasons; see Section 5.4. To assure that the alternative 
| service has opted into serving HTTP URLs over TLS, clients MUST check the “http-opportunistic” 
| well-known URI defined in Section 3 before directing HTTP requests to it.

and then

5.4 Confusion Regarding Request Scheme
http://httpwg.org/http-extensions/opsec.html#confuse

and

3. The “http-opportunistic” well-known URI
http://httpwg.org/http-extensions/opsec.html#well-known


and either

2.2 Interaction with “https” URIs
http://httpwg.org/http-extensions/opsec.html#rfc.section.2.2

| Because of the risk of server confusion about individual requests’ schemes (see Section 5.4), 
| clients MUST NOT mix “https” and “http” requests on the same connection unless the 
| http-opportunistic response’s origin object Section 3 has a “mixed-scheme” member whose value 
| is “true”.


does not make clear that this “mixed-scheme” check must be done for http-opportunistic resource
returned by chosen alternative service.


After all it is chosen alternative service which can be confused about scheme.


2.1 Alternative Server Opt-In
http://httpwg.org/http-extensions/opsec.html#rfc.section.2.1

there is

| The chosen alternative service returns the same representation as the origin did for the 
| http-opportunistic resource.

but that only apply when determining  “reasonable assurances”.


Or have I missed something?

/ Kari Hurtta