Subject: Re: [httpwg/http-extensions] DNS relaxation, smaller initial Origin Set (#285)

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 02:05:53 -0800

martinthomson commented on this pull request.

This all assumes use of `https`.  That's probably an error because for `http` you have just provided a perfect hijacking mechanism.  We already have enough of those for cleartext HTTP thanks very much :)

I would strongly recommend explicitly limiting this feature to `https` based on the current changes.

> @@ -101,49 +106,65 @@ REMOVE (0x2):
 The set of origins (as per {{!RFC6454}}) that a given connection might be used for is known in this
 specification as the Origin Set.
 
-When a connection is first established, its Origin Set is defined to be those origins that the client would normally consider the connection authoritative for; see {{!RFC7540}}, Section 10.1.
+When a connection is first established, its Origin Set is defined to be the origin composed from:
+  - Scheme: "https"
+  - Host: the value sent in Server Name Indication {{!RFC6066}}
+  - Port: the local port of the connection on the server
+
+If SNI is not sent, the Origin Set is empty when the connection is established.

This is a retroactive change to h2.  It says that you can't coalesce.  It also says that you can't *use* a connection if you didn't use SNI.  I think that you need to include some weasel-words about how this doesn't really apply until the first ORIGIN frame is sent or received.

>     2. If the REMOVE flag is set, remove any member of the Origin Set that is the same as `parsed_origin` (as per {{!RFC6454}}, Section 5), and continue to the next `parsed_origin`.
    3. Otherwise, add `parsed_origin` to the Origin Set.

 # Security Considerations
 
 Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of
-attacks; hence the reinforcement that this specification does not relax the requirement for server
-authority in {{?RFC7540}}, Section 10.1.
+attacks.

Rather than simple removal, I would add:

> Though this document removes the requirement on clients to ensure that the DNS refers to the same IP address, it does not remove the requirement for certificate-based authentication.  A client MUST validate a server IP address.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#pullrequestreview-19514250

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 16:56:09 -0800

@mnot pushed 1 commit.

eaa6a4b  note unicode

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/241ce50734215f15c7af2e65921e710d8f977638..eaa6a4bd547bcee8eabc9d72a535eea4f68c1aaa

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:19:38 -0800

@mnot pushed 1 commit.

de47d40  rewrite after discussion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/eaa6a4bd547bcee8eabc9d72a535eea4f68c1aaa..de47d40db2c9ca06eb98678e45ebab3f0253fda4

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:23:59 -0800

@mnot pushed 1 commit.

8171ff1  fix ref

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/de47d40db2c9ca06eb98678e45ebab3f0253fda4..8171ff1cd2d252a7a25980c510f1e9401b6a4339

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:30:47 -0800

@mnot pushed 1 commit.

835e8d9  Update 5987bis.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/8171ff1cd2d252a7a25980c510f1e9401b6a4339..835e8d99bc357101a8869a1415b4cdacb69f2a15

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:35:12 -0800

@mnot pushed 1 commit.

d4bf661  local -> remote

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/835e8d99bc357101a8869a1415b4cdacb69f2a15..d4bf661368ff53a5a49c4d67e4c93348513c8a42

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:38:51 -0800

@mnot pushed 1 commit.

6529f68  add placeholder for IANA considerations.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/d4bf661368ff53a5a49c4d67e4c93348513c8a42..6529f681194b5d70612865b8dd1a36aeea7451eb

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 18:39:13 -0800

@mnot pushed 1 commit.

6b932b2  I spel gud

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/6529f681194b5d70612865b8dd1a36aeea7451eb..6b932b2a5fca88705afabb23f938afe8d81129fe

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 19:55:23 -0800

@mnot pushed 1 commit.

91b2a4e  add "note that..."

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/6b932b2a5fca88705afabb23f938afe8d81129fe..91b2a4e57d70967452c9e56617ff40ac27b1c1f8

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 01 Feb 2017 22:21:49 -0800

@mnot pushed 1 commit.

227694d  more HTTPS getout clause

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/91b2a4e57d70967452c9e56617ff40ac27b1c1f8..227694d092a8ce0fc88d044bdba8c0e4530eb2a9

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 02 Feb 2017 15:55:44 -0800

@mnot pushed 3 commits.

66463b0  - Reserve some flags for backwards-incompatible changes
a77c322  add IANA considerations
4d3cf21  Martin's suggestion (modified)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/227694d092a8ce0fc88d044bdba8c0e4530eb2a9..4d3cf21550ed4dc84cd6d802e5ae24e7a01c412f

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 02 Feb 2017 16:37:17 -0800

@mnot pushed 5 commits.

b2a7bc2  change TLS step
f27c5e0  Tweak "initialised"
31fea62  add operational considerations
0b6affa  talk about conn de-duplication
8afa09b  clarify

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/4d3cf21550ed4dc84cd6d802e5ae24e7a01c412f..8afa09b580bf52df234522ce8397e67ff8274e76

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 02 Feb 2017 16:56:48 -0800

martinthomson approved this pull request.

This is looking good.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#pullrequestreview-19929547

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 08:09:58 -0800

mcmanus commented on this pull request.

this is indeed looking good

> @@ -58,6 +58,11 @@ Using a status code in this manner allows clients to recover from misdirected re
 penalty of adding latency. To address that, this specification defines a new HTTP/2 frame type,
 "ORIGIN", to allow servers to indicate what origins a connection is usable for.
 
+Additionally, experience has shown that HTTP/2's requirement to establish server authority using
+both DNS and the server's certificate is onerous. This specification relaxes the requirement to
+check DNS when the ORIGIN frame is in use.
+
+

nit extra newline

-REMOVE (0x2): 
-: Indicates that the origin(s) carried in the payload must be removed from the Origin Set, if present; if not present, it/they have no effect.
+This specification does not define any flags for the ORIGIN frame, but future updates might use
+them to change its semantics. The first four flags (0x1, 0x2, 0x4 and 0x8) are reserved for

this is a whole new, albeit interesting!, way of versioning. is this the place to break that ground?

-REMOVE (0x2): 
-: Indicates that the origin(s) carried in the payload must be removed from the Origin Set, if present; if not present, it/they have no effect.
+This specification does not define any flags for the ORIGIN frame, but future updates might use
+them to change its semantics. The first four flags (0x1, 0x2, 0x4 and 0x8) are reserved for
+backwards-incompatible changes, and therefore when any of them are set, the ORIGIN frame containing
+them MUST be ignored by clients conforming to this specification. The remaining flags are reserved
+for backwards-compatible changes, and do not affect processing by clients conformant to this
+specification.
+
+The ORIGIN frame is processed hop-by-hop. An intermediary MUST NOT forward ORIGIN frames. Clients

clarifying suggestion: The ORIGIN frame describes a property of the connection, and therefore  is processed hop-by-hop.

> +specification.
+
+The ORIGIN frame is processed hop-by-hop. An intermediary MUST NOT forward ORIGIN frames. Clients
+configured to use a proxy MUST ignore any ORIGIN frames received from it.
+
+Each ASCII-Origin field in the frame's payload MUST be parsed as an ASCII serialisation of an
+origin ({{!RFC6454}}, Section 6.2). If parsing fails, the field MUST be ignored.
+
+Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be
+case-normalised before serialisation.
+
+Once parsed, the value MUST have:
+
+* a scheme of "https", 
+* a host that is reflected in a `subjectAltName` of the connection's TLS certificate (using the wildcard rules defined in {{!RFC2818}}, Section 3.1), and 
+* a port that reflects the connection's remote port on the client. 

hmm. how does this interact with Alt-Svc? Seems that you could be connected to a port number different than the origin port number (thanks to Alt-Svc) and still want to use origin frames.

-The ORIGIN frame allows the server to modify the Origin Set. In particular:
+  - Scheme: "https"
+  - Host: the value sent in Server Name Indication ({{!RFC6066}} Section 3), converted to lower case
+  - Port: the local port of the connection on the server

alt-svc concern applies here too wrt port

> @@ -58,6 +58,11 @@ Using a status code in this manner allows clients to recover from misdirected re
 penalty of adding latency. To address that, this specification defines a new HTTP/2 frame type,
 "ORIGIN", to allow servers to indicate what origins a connection is usable for.
 
+Additionally, experience has shown that HTTP/2's requirement to establish server authority using

in discussions on this there are a couple of other motivators that may (or may not!) be worth including as introductory text.. one is simply that it can save a dns lookup by effectively inlining the result and the other is that dns is often a privacy leak that can be avoided by not making the lookup

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#pullrequestreview-20027455

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 11:33:32 -0800

deweerdt commented on this pull request.

minor nits

>  +-------------------------------+-------------------------------+
 ~~~~
 
 The ORIGIN frame's payload contains the following fields, sets of which may be repeated within the
 frame to indicate multiple origins:
 
 Origin-Len:
-: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.
+: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field.

Should this mention network ordering?

+1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing.
+2. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing.
+3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing.
+4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the frame and stop processing.
+5. If no previous ORIGIN frame on the connection has reached this step, initialise the Origin Set as per {{set}}.
+6. For each Origin field `origin_raw` in the frame payload:
+   1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`.
+   2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`.
+   3. If the certificate presented by the server is not valid for the `host` of `parsed_origin` (see below), skip to the next `origin_raw`.
+   4. If the `port` of `parsed_origin` does not match the connection's remote port, skip to the next `origin_raw`.
+   5. Add `parsed_origin` to the Origin Set.
+
+The certificate presented by the server is valid for a host if it passes the checks that the client
+would perform when forming a new TLS connection to the origin. This includes verifying that the
+host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules

typo: s/sNSName/DNSName/

> +6. For each Origin field `origin_raw` in the frame payload:
+   1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`.
+   2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`.
+   3. If the certificate presented by the server is not valid for the `host` of `parsed_origin` (see below), skip to the next `origin_raw`.
+   4. If the `port` of `parsed_origin` does not match the connection's remote port, skip to the next `origin_raw`.
+   5. Add `parsed_origin` to the Origin Set.
+
+The certificate presented by the server is valid for a host if it passes the checks that the client
+would perform when forming a new TLS connection to the origin. This includes verifying that the
+host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules
+defined in {{!RFC2818}}).
+
+
+# Operational Considerations for Servers {#server-ops}
+
+The ORIGIN frame allows a server to indicate what for origins a given connection ought be used.

s/to indicate what for origins/to indicate for which origins/

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#pullrequestreview-20085980

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:25:45 -0800

mnot commented on this pull request.

-REMOVE (0x2): 

Well, it has to be somewhere. I did it here because there seem to be some cases that require a breaking change (e.g., if we want to include a DELETE or CLEAR flag down the road), and some that don't (e.g., wildcard support).

Happy to take it out (there are always more ways to do it), but it seemed mostly harmless to try it out here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:30:32 -0800

already fixed

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:30:38 -0800

already fixed

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:33:11 -0800

Is correct; see https://tools.ietf.org/html/rfc5280#section-4.2.1.6 (but will add a ref)

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:27:14 -0800

~~~~

 Origin-Len:

Convention is not to in new frame types, since H2 defines it.

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:36:18 -0800

Done

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:46:04 -0800

@mnot pushed 4 commits.

cc16f7d  Patrick's suggestion about hop-by-hop
5a9a667  deweert suggestion
93d2b92  add 5280 ref
213b958  Add motivation

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/8afa09b580bf52df234522ce8397e67ff8274e76..213b958c421f2077ea86295d3b3ae753bfb04317

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 03 Feb 2017 16:48:19 -0800

+

Yeah. need to think about how to best specify that.

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Feb 2017 16:52:01 -0800

@mnot pushed 2 commits.

2315727  defer checks on origin to use
8520938  move note about case to server-ops

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/213b958c421f2077ea86295d3b3ae753bfb04317..85209385ab88ed6d90f2507d47fc2e7865516a6e

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Feb 2017 16:52:50 -0800

+

@mcmanus see latest commit; I defer the cert checks until use of the origin, and I think that takes care of the concerns here.

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Feb 2017 18:15:17 -0800

I'm inclined to think that if you want to host an alternative service and send ORIGIN, you need to explicitly list the alternative in ORIGIN. The client *could* make some assumptions, but that doesn't seem great. Thoughts?

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 06 Feb 2017 18:15:53 -0800

@mnot pushed 1 commit.

6b3b761  correct port

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/85209385ab88ed6d90f2507d47fc2e7865516a6e..6b3b76186c3eecbeace6bbd7bbbb8a040b502006

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 07 Feb 2017 09:55:37 -0800

On Mon, Feb 6, 2017 at 9:15 PM, Mark Nottingham <[email-masked]>
wrote:

> I'm inclined to think that if you want to host an alternative service and
> send ORIGIN, you need to explicitly list the alternative in ORIGIN. The
> client *could* make some assumptions, but that doesn't seem great.
> Thoughts?
>

wait - no. You wouldn't send the alternative in the ORIGIN frame, you would
send the origin that you are the alternative for, right? that would make
sense - if you want to use an alternative you can't rely on the SNI default.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#issuecomment-278083944

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 12 Feb 2017 21:20:21 -0800

@mnot pushed 1 commit.

e2083ad  Note interaction with Alt-Svc.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/httpwg/http-extensions/pull/285/files/6b3b76186c3eecbeace6bbd7bbbb8a040b502006..e2083ad3938f7f335ef4051ce5edfb03259fdcd7

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 12 Feb 2017 21:25:24 -0800

Merged #285.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/pull/285#event-959037297