Subject: Re: Op-sec simplification

From: Kari Hurtta <[email-masked]>
Date: Mon, 31 Oct 2016 07:32:39 +0200 (EET)

| https://github.com/httpwg/http-extensions/pull/254
| 
| The main changes:
| 
|  - the .well-known resource is a flat list of origins

( no comment about that yet. )

|  - the client only needs to acquire a .wk from the secured server

Hmm. Reading it from original and from the secured server
gives little more verify that they really are giving same answers.

| - the draft explicitly allows HTTP/1.1

https://github.com/httpwg/http-extensions/blob/967aa51e513e4a2eea39ce6b2a37789be05c9483/draft-ietf-httpbis-http2-encryption.md#using-http-uris-over-tls

| Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of {{RFC7230}}).

Yes, I suggested that.

Example needs also to use absolute form here:

https://github.com/httpwg/http-extensions/blob/967aa51e513e4a2eea39ce6b2a37789be05c9483/draft-ietf-httpbis-http2-encryption.md#alternative-server-opt-in-auth

| GET /.well-known/http-opportunistic HTTP/1.1
| Host: www.example.com

( I think that I mentioned that example also. )

So it should be

| GET http://www.example.com/.well-known/http-opportunistic HTTP/1.1
| Host: www.example.com

( Seems that "Host" header is required also when absolute form is used. 
  That I missed last time
  https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0097.html
)

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Oct 2016 20:57:56 +1100

> gives little more verify that they really are giving same answers.

Yes, but as I observed, we're never truly certain; there's always a
pathological case where a client can be convinced of the server being
right when it is in fact wrong.  Asking both sides only adds to the
complexity of the solution.

> | GET http://www.example.com/.well-known/http-opportunistic HTTP/1.1

Yes, thanks for pointing that out.  Fixed.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Oct 2016 20:00:20 +0000

I like the direction this is moving, yes.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, October 31, 2016 2:58 AM
To: Kari Hurtta <[email-masked]>
Cc: HTTP working group mailing list <[email-masked]>
Subject: Re: Op-sec simplification

On 31 October 2016 at 16:32, Kari Hurtta <[email-masked]> wrote:
> Hmm. Reading it from original and from the secured server gives little 
> more verify that they really are giving same answers.

Yes, but as I observed, we're never truly certain; there's always a pathological case where a client can be convinced of the server being right when it is in fact wrong.  Asking both sides only adds to the complexity of the solution.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Nov 2016 09:41:56 +1100

Hold on -- are we layering in a new requirement to use the absolute form of the URL?

That's going to cause issues with a number of client and server side implementations that don't have control over or access to the precise form of the URL on the wire.

It also violates a MUST in 7230, 5.3.1:

"""
When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target.
"""

Cheers,

> On 31 Oct. 2016, at 4:32 pm, Kari Hurtta <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Nov 2016 10:15:13 +1100

> Hold on -- are we layering in a new requirement to use the absolute form of the URL?

I don't know how we carry the scheme any other way.  We might try to
weasel this as being not "directly" to the origin server.

Maybe I should point out that this is in contradiction to that section.

(FWIW, the servers I'm aware of all handle absolute URIs well enough.)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Nov 2016 10:17:04 +1100

> On 1 Nov. 2016, at 10:15 am, Martin Thomson <[email-masked]> wrote:
> 

I suspect someone with a process bent will say that it needs to update 7230, and having an experimental doc update a standards track one might be... interesting. I suppose if we have consensus to do it, it might work.

> (FWIW, the servers I'm aware of all handle absolute URIs well enough.)

Is there an implicit requirement for them to check that it was absolute?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Nov 2016 10:25:46 +1100

Yes. What I meant was whether the opp-sec spec is writing in an implicit requirement to assure that it was absolute (for that request).

> On 1 Nov. 2016, at 10:24 am, Mike Bishop <[email-masked]> wrote:
> 
> There's an explicit requirement in RFC 7230 for servers to accept it:
>>  To allow for transition to the absolute-form for all requests in some
>>  future version of HTTP, a server MUST accept the absolute-form in
>>  requests, even though HTTP/1.1 clients will only send them in
>>  requests to proxies.
> 
> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Monday, October 31, 2016 4:17 PM
> To: Martin Thomson <[email-masked]>
> Cc: Kari Hurtta <[email-masked]>; HTTP working group mailing list <[email-masked]>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 31 Oct 2016 23:24:46 +0000

---

From: Patrick McManus <[email-masked]>
Date: Mon, 31 Oct 2016 20:36:55 -0400

or we just punt the legacy h1 cases away. I'm not aware of anyone doing an
experiment with them.

On Mon, Oct 31, 2016 at 7:25 PM, Mark Nottingham <[email-masked]> wrote:

> Yes. What I meant was whether the opp-sec spec is writing in an implicit
> requirement to assure that it was absolute (for that request).
>
>
> > I suspect someone with a process bent will say that it needs to update
> 7230, and having an experimental doc update a standards track one might
> be... interesting. I suppose if we have consensus to do it, it might work.
> >
> >

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 1 Nov 2016 07:14:05 +0200 (EET)

Mark Nottingham <[email-masked]>: (Tue Nov  1 00:41:56 2016)
> That's going to cause issues with a number of client and server side implementations that don't have control over or access to the precise form of the URL on the wire.

My original text suggestion was

|  When client send "http" requests over a TLS connection request
|  request MUST include scheme. This means that when used with
|  protocol identifier "http/1.1" (TTP/1.1 over TLS), request uses
|  absoluteURI -form.

That is somewhat indirect requirement ☺
 
> When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the ta…

Then net result mey be  that do not use "http/1.1" but request need to be include
scheme anyway.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 1 Nov 2016 07:25:08 +0200 (EET)

Mark Nottingham <[email-masked]>: (Tue Nov  1 01:17:04 2016)
> > Maybe I should point out that this is in contradiction to that section.

That may be good idea. (This spec requires scheme and http/1.1 spec does not
allow scheme to be used. )

> Is there an implicit requirement for them to check that it was absolute?

Well, I suggested that on https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0102.html

|  This specification registers a (HTTP) Status Codes:
|
|  [TO BE REMOVED: Hypertext Transfer Protocol (HTTP) Status Code Registry
|   http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ]
|
|   +-------+-------------------------------+-------------+
|   | Value | Description                   | Reference   |
|   +-------+-------------------------------+-------------+
|   | TBD1  | Scheme Not Allowed            | Section 2.2 |
|   | TBD2  | Scheme Required               | Section 2.1 |
|   +-------+-------------------------------+-------------+
|
|   [TO BE REMOVED: TBD1 and TBD2 are from 4xx range. ]

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Nov 2016 16:54:29 +1100

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