Subject: Re: h2 requirements on authoritative responses

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Sep 2014 16:55:50 -0700

This is good feedback.  One consequence of inheriting SPDY was that
there was a lot of effort put in there to avoid intermediation.  Some
of this definitely shows in the form of "uncollected garbage", that is
true.

I'll send out proposed change sets once I've bashed on this a little
so that everyone can review the changes more thoroughly.  I won't push
this straight into the editor's copy until I'm satisfied that everyone
is happy.

On 31 August 2014 19:09, Roy T. Fielding <[email-masked]> wrote:
> Note that the above forbids proxies.  A proxy is unlikely to be authoritative
> for the resources that it is being used to proxy.

That was not intentional.  I'll attempt to correct that.  I'm sure
that I'll get it wrong at first.

>>    For "https" resources, connection reuse additionally depends on
>>    having a certificate that is valid for the host in the URI.  That is
>>    the use of server certificate with multiple "subjectAltName"
>>    attributes, or names with wildcards.  For example, a certificate with
>>    a "subjectAltName" of "*.example.com" might permit the use of the
>>    same connection for "a.example.com" and "b.example.com".
>
> Again, forbids making a connection to a proxy in order to have it make
> an https request (e.g., CONNECT in section 8.3).

> The above paragraphs need to be rewritten, perhaps by separating them
> into separate sections on "how to make requests of an origin server"
> and "how to make requests of a proxy". These requirements have little
> to do with making a connection.

I think that it's sufficient to talk about connection reuse outside of
the proxy context.  That makes this a lot easier, I think.

>>    In some deployments, reusing a connection for multiple origins can
>>    result in requests being directed to the wrong origin server.  For
>>    example, TLS termination might be performed by a middlebox that uses
>>    the TLS Server Name Indication (SNI) [TLS-EXT] extension to select
>>    the an origin server.  This means that it is possible for clients to
>>    send confidential information to servers that might not be the
>>    intended target for the request, even though the server has valid
>>    authentication credentials.
>
> (editorial) "the an origin" -> "an origin".  I think this is an odd
> discussion given that this section is not about TLS connections.

A change in emphasis avoids that issue, I hope.

>>    A server that does not wish clients to reuse connections can indicate
>>    that it is not authoritative for a request by sending a 421 (Not
>>    Authoritative) status code in response to the request (see
>>    Section 9.1.2).
>
> That's not actually what it wants to say.  I have suggested
> such a code before, though I called it 4xx Misdirected Request.

I'll take that, "Not Authoritative" was only a name awaiting a
suggestion like this.

It will take a small amount of rewording to ensure that this is the
emphasis, rather than on authority.

>> 10.1.  Server Authority
>>
>>    A client is only able to accept HTTP/2 responses from servers that
>>    are authoritative for those resources.  This is particularly
>>    important for server push (Section 8.2), where the client validates
>>    the PUSH_PROMISE before accepting the response.
>
> Again, explicitly forbids the use of proxies (and shared caches).
> Repeated in section 10.4.
>
>>    HTTP/2 relies on the HTTP/1.1 definition of authority for determining
>>    whether a server is authoritative in providing a given response, see
>>    [RFC7230], Section 9.1.  This relies on local name resolution for the
>>    "http" URI scheme, and the authenticated server identity for the
>>    "https" scheme (see [RFC2818], Section 3).
>>
>>    A client MUST discard responses provided by a server that is not
>>    authoritative for those resources.
>
> That was a limitation of SPDY, so I suspect this may be uncollected garbage.

What a nice way of putting it.

I've removed the paragraphs that I think were the cause of the
offense, which should have no material impact on the interpretation of
the document.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Sep 2014 17:22:51 -0700

> I'll send out proposed change sets once I've bashed on this a little

First, removal from 10.1:

REMOVE:
-          A client is only able to accept HTTP/2 responses from
servers that are authoritative for
-          those resources.  This is particularly important for <xref
target="PushResources">server
-          push</xref>, where the client validates the
<x:ref>PUSH_PROMISE</x:ref> before accepting
-          the response.
REMOVE:
-          A client MUST discard responses provided by a server that
is not authoritative for those
-          resources.

Both of these statements simply aren't true in the proxy case.

Second, rewording 9.1.1 to allow for the proxy stuff:

OLD:
-            Clients MAY use a single server connection to send
requests for URIs with multiple
-            different authority components as long as the server is <xref
-            target="authority">authoritative</xref>.
NEW:
+            Connections that are made to origin servers without a
proxy or tunnels created using the
+            <xref target="CONNECT">CONNECT method</xref> MAY be
reused for requests with multiple
+            different URI authority components.  A connection can be
reused as long as the server is
+            <xref target="authority">authoritative</xref>.
KEEP:
            For <spanx style="verb">http</spanx>
             resources, this depends on the host having resolved to
the same IP address.

             For <spanx style="verb">https</spanx> resources,
connection reuse additionally depends
             on having a certificate that is valid for the host in the URI.
OLD:
-           That is the use of
-            server certificate with multiple <spanx
style="verb">subjectAltName</spanx> attributes,
-            or names with wildcards.  For example, a certificate with a <spanx
-            style="verb">subjectAltName</spanx> of <spanx
style="verb">*.example.com</spanx> might
-            permit the use of the same connection for <spanx
style="verb">a.example.com</spanx> and
-            <spanx style="verb">b.example.com</spanx>.
NEW:
+           That is the use of
+            on having a certificate that is valid for the host in the
URI.  A server might offer a
+            certificate with multiple <spanx
style="verb">subjectAltName</spanx> attributes, or
+            names with wildcards, one of which is valid for the
authority in the URI.  For example,
+            a certificate with a <spanx
style="verb">subjectAltName</spanx> of <spanx
+            style="verb">*.example.com</spanx> might permit the use
of the same connection for
+            requests to URIs starting with <spanx
style="verb">https://a.example.com/</spanx> and
+            <spanx style="verb">https://b.example.com/</spanx>.

KEEP:
            In some deployments, reusing a connection for multiple
origins can result in requests
             being directed to the wrong origin server.  For example,
TLS termination might be
             performed by a middlebox that uses the TLS <xref
target="TLS-EXT">Server Name Indication
             (SNI)</xref> extension to select  an origin server. This
means that it is possible
             for clients to send confidential information to servers
that might not be the intended
OLD:
-            target for the request, even though the server has valid
authentication credentials.
NEW:
+            target for the request, even though the server is
otherwise authoritative.

ADD:
+            A client that is configured to use a proxy directs
requests to that proxy through a
+            single connection.  That is, all requests sent via a
proxy reuse the connection to the
+            proxy.

And I found some collateral in the description of push:

OLD:
-            Clients receiving a pushed response MUST validate that
the server is authoritative for
-            it; see <xref target="authority"/>. For example, a server
that offers a certificate for
-            only the <spanx style="verb">example.com</spanx> DNS-ID
or Common Name is not permitted
-            to push a response for <spanx
style="verb">https://www.example.org/doc</spanx>.
NEW:
+            Clients receiving a pushed response MUST validate that
either the server is
+            authoritative (see <xref target="authority"/>), or the
proxy that provided the pushed
+            response is configured for the corresponding request. For
example, a server that offers
+            a certificate for only the <spanx
style="verb">example.com</spanx> DNS-ID or Common Name
+            is not permitted to push a response for <spanx
+            style="verb">https://www.example.org/doc</spanx>.

I'll follow up with renaming of the status code.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Sep 2014 13:40:00 +1200

On 3/09/2014 12:22 p.m., Martin Thomson wrote:
> REMOVE: -          A client is only able to accept HTTP/2 responses
> from servers that are authoritative for -          those resources.
> This is particularly important for <xref 
> target="PushResources">server -          push</xref>, where the
> client validates the <x:ref>PUSH_PROMISE</x:ref> before accepting -
> the response. REMOVE: -          A client MUST discard responses
> provided by a server that is not authoritative for those -
> resources.
> 

As I recall, the intent behind those was to prevent intermediaries
generating content which gets confused for authoritative info.
 Perhapse re-emphasise mandatory use of 203 status and Warning 214
code from RFC723x instead of the prohibition?

> OLD: -            Clients MAY use a single server connection to
> send requests for URIs with multiple -            different
> authority components as long as the server is <xref -
> target="authority">authoritative</xref>. NEW: +
> Connections that are made to origin servers without a proxy or
> tunnels created using the +            <xref
> target="CONNECT">CONNECT method</xref> MAY be reused for requests
> with multiple +            different URI authority components.  A
> connection can be reused as long as the server is +
> <xref target="authority">authoritative</xref>. KEEP: For <spanx
> style="verb">http</spanx> resources, this depends on the host
> having resolved to the same IP address.

IMO this KEEP part needs to mention port remaining the same as well.
That will avoid interop problems with port-based load balancer gateways.

> 
> For <spanx style="verb">https</spanx> resources, connection reuse
> additionally depends on having a certificate that is valid for the
> host in the URI. OLD: -           That is the use of -
> server certificate with multiple <spanx 
> style="verb">subjectAltName</spanx> attributes, -            or
> names with wildcards.  For example, a certificate with a <spanx -
> style="verb">*.example.com</spanx> might -            permit the
> use of the same connection for <spanx 
> style="verb">a.example.com</spanx> and -            <spanx
> style="verb">b.example.com</spanx>. NEW: +           That is the
> use of +            on having a certificate that is valid for the
> host in the URI.  A server might offer a +            certificate
> with multiple <spanx style="verb">subjectAltName</spanx>
> attributes, or +            names with wildcards, one of which is
> valid for the authority in the URI.  For example, +            a
> certificate with a <spanx style="verb">subjectAltName</spanx> of
> <spanx +            style="verb">*.example.com</spanx> might permit
> the use of the same connection for +            requests to URIs
> starting with <spanx style="verb">https://a.example.com/</spanx>
> and +            <spanx
> style="verb">https://b.example.com/</spanx>.
> 

Could also mention that DANE provides and alternative method of
receiving certificates and RFC6698 section 5 explicitly documents as
being possible to have multiple TLSA records with different contents
for rollover and combination cases.

ie. we need to be careful that we do not make h2 incompatible with
multi-certificate origins any more than with wildcard or
multi-subjectAltName origins.

> 
> KEEP: In some deployments, reusing a connection for multiple 
> origins can result in requests being directed to the wrong origin
> server.  For example, TLS termination might be performed by a
> middlebox that uses the TLS <xref target="TLS-EXT">Server Name
> Indication (SNI)</xref> extension to select  an origin server.
> This means that it is possible for clients to send confidential
> information to servers that might not be the intended OLD: -
> target for the request, even though the server has valid 
> authentication credentials. NEW: +            target for the
> request, even though the server is otherwise authoritative.
> 
> ADD: +            A client that is configured to use a proxy
> directs requests to that proxy through a +            single
> connection.  That is, all requests sent via a proxy reuse the
> connection to the +            proxy.
> 

+1.

> OLD: -            Clients receiving a pushed response MUST validate
> that the server is authoritative for -            it; see <xref
> target="authority"/>. For example, a server that offers a
> certificate for -            only the <spanx
> style="verb">example.com</spanx> DNS-ID or Common Name is not
> permitted -            to push a response for <spanx 
> style="verb">https://www.example.org/doc</spanx>. NEW: +
> Clients receiving a pushed response MUST validate that either the
> server is +            authoritative (see <xref
> target="authority"/>), or the proxy that provided the pushed +
> response is configured for the corresponding request. For example,
> a server that offers +            a certificate for only the
> <spanx style="verb">example.com</spanx> DNS-ID or Common Name +
> is not permitted to push a response for <spanx +

+1.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Sep 2014 09:29:42 +0300

Hi Roy,

I’ve reopened <https://github.com/http2/http2-spec/issues/413>, marked it editorial and linked to this.

Cheers,

On 1 Sep 2014, at 5:09 am, Roy T. Fielding <[email-masked]> wrote:

> This comment is in reference to sections 9.1.1-2, 10.1, and 10.4 of
> 
> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
> 
> I don't know how much of this is just a remnant from SPDY or an
> intention of the draft authors.  Proxies are considered by
> most folks to be an important aspect of HTTP.  In general, it is
> the responsibility of the client to decide whether it trusts a
> proxy enough to make use of proxied responses.  If it doesn't,
> it seems unlikely that the client would use the proxy to send requests.
> It certainly doesn't make sense for the client to use a proxy for
> requests if it also intends to discard the responses.
> 
>> 9.1.1.  Connection Reuse
>> 
>>   Clients MAY use a single server connection to send requests for URIs
>>   with multiple different authority components as long as the server is
>>   authoritative (Section 10.1).  For "http" resources, this depends on
>>   the host having resolved to the same IP address.
> 

Well, it’s a MAY, not a MUST NOT — nothing is forbidden by the requirement above. Could it be written more helpfully? Sure.

>> 9.1.2.  The 421 (Not Authoritative) Status Code
>> 
>>   The 421 (Not Authoritative) status code indicates that the current
>>   origin server is not authoritative for the requested resource, in the
>>   sense of [RFC7230], Section 9.1 (see also Section 10.1).
>> 
>>   Clients receiving a 421 (Not Authoritative) response from a server
>>   MAY retry the request - whether the request method is idempotent or
>>   not - over a different connection.  This is possible if a connection
>>   is reused (Section 9.1.1) or if an alternative service is selected
>>   ([ALT-SVC]).
>> 
>>   This status code MUST NOT be generated by proxies.
>> 
>>   A 421 response is cacheable by default; i.e., unless otherwise
>>   indicated by the method definition or explicit cache controls (see
>>   Section 4.2.2 of [RFC7234]).
> 
> Like I said, "Misdirected Request" is a better name for this code.
> 
> 
>> 10.1.  Server Authority
>> 
> *facepalm*
> It is good to know when a response is authoritative (blessed or
> generated by the origin) or not.  However, forbidding non-authoritative
> responses is not (and has never been) a feature of HTTP.  Cached
> responses, for example, are non-authoritative unless validated with
> the origin server.  I will be somewhat bummed if HTTP/2 forbids
> unvalidated caching.
> 
> Cheers,
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <http://www.adobe.com/>
> 
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 11:44:45 -0700

> That will avoid interop problems with port-based load balancer gateways.

With respect to authority, HTTP/1.1 doesn't rely on that.  You should
probably direct comments of this nature to the alternative services
draft instead.

> multi-subjectAltName origins.

The use of subjectAltName is intentionally exemplary for that reason.
The normative statements should still apply to DANE and other related
functions like pinning.  But I think that it's important to cover the
most common cases in the example to help avoid confusion where it
matters most.  (That is, until DANE is more commonplace; I've not yet
heard of a single use of it on the web.)

---

From: Guille -bisho- <[email-masked]>
Date: Wed, 3 Sep 2014 12:05:16 -0700

> proxy reuse the connection to the

"MAY" missing here? Clients might want to use more than one connection
even if they can multiplex on one.
-- 
Guille -ℬḭṩḩø- <[email-masked]>
:wq

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 12:45:39 -0700

And the description of the renamed status code.

NEW:
+            The 421 (Misdirected Request) status code indicates that
the request was directed at a
+            server that is not able to produce a response.  This can
be sent by a server that is no
+            configured to produce responses for the combination of
scheme and authority that are^M
+            included in the request URI.

Which is all in the pull request that I'll merge as soon as I'm happy
that these won't immediately churn:

https://github.com/http2/http2-spec/pull/606

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 12:48:07 -0700

> even if they can multiplex on one.

As much as possible, we're avoiding any statements that might imply
any form of blessing on the use of >1 connection to a given server.
The reasons for having more connections are largely spurious.  Other
than in transitory conditions that is, like when you have run out of
stream identifiers and need to spin up a replacement connection
gracefully.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 13:32:08 -0700

> Both of these statements simply aren't true in the proxy case.

+1

> +            <xref target="authority">authoritative</xref>.

A slight (editorial) suggestion:

  Connections that are made to an origin server, either directly or
  through a tunnel created using the <xref target="CONNECT">CONNECT method</xref>,
  MAY be reused for requests with different URI authority components
  if that origin server is also <xref target="authority">authoritative</xref>
  for those other authority components.

though this begs the question: why is this a MAY instead of a
MUST NOT ... unless X?

>             on having a certificate that is valid for the host in the URI.

+1

> +            <spanx style="verb">https://b.example.com/</spanx>.

First sentence seems a bit garbled.  I suggest using "origin server" here
instead of server.

> +            target for the request, even though the server is

+1

> proxy reuse the connection to the

In general, I don't think the protocol should specify such things.
A proxy might not even be using HTTP to its clients, for example.

> +            style="verb">https://www.example.org/doc</spanx>.

+1

Thanks,

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 13:37:31 -0700

On Sep 3, 2014, at 12:45 PM, Martin Thomson wrote:

> be sent by a server that is not
> scheme and authority that are

+1

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 13:49:13 -0700

>   for those other authority components.

Thanks.

> though this begs the question: why is this a MAY instead of a

Mainly because they are basically the same in effect, but a positively
worded statements is easier to comprehend.

A MUST NOT would require two exclusions: one for connections directly
to proxies (easy) and the other for origin servers that offer
credentials that are valid for the other domain.  It seems like a net
zero gain.

> First sentence seems a bit garbled.

That's because I botched up the copy paste in my haste.  The text I
have is instead

    For "https" resources, connection reuse additionally depends on
   having a certificate that is valid for the host in the URI.  A server
   might offer a certificate [...]

> I suggest using "origin server" here instead of server.

Thanks.

> A proxy might not even be using HTTP to its clients, for example.

Would limiting the scope to a proxy *using HTTP/2* suffice?  I think
that this is still of some use.

---

From: Daniel Sommermann <[email-masked]>
Date: Wed, 3 Sep 2014 13:58:47 -0700

On 09/03/2014 12:48 PM, Martin Thomson wrote:
> The reasons for having more connections are largely spurious.

On lossy links, TCP's retransmission will lead to HOL. In this case, 
having multiple connections may help increase goodput. I'd rather the 
spec just didn't mention the number of connections to a server at all.

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 4 Sep 2014 07:57:34 +1000

Just some tiny nits. Sorry if they're not in the actual PR, I can't
check as github and my phone don't play so nicely.

> be sent by a server that is no

not?

> scheme and authority that are^M

Windows editor?

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 15:04:54 -0700

> not?

Copy-paste truncation only.

>> scheme and authority that are^M

Windows-format file on a non-Windows platform :)  Editors have been
able to handle that gracefully for years now.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 15:55:20 -0700

> that this is still of some use.

I don't think it will be true of HTTP/2 either, at least not uniformly.
The nature of proxies is such that they usually optimize for local network
constraints rather than what would be "normal" for the global Internet.
We usually don't care because most proxies are inside corporate intranets.

The public Internet proxies tend to be privacy proxies, which might
do very strange things with their connections just to provide
sufficient incoming traffic to mask where the outgoing traffic came from.

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 17:20:59 -0700

> I don't think it will be true of HTTP/2 either, at least not uniformly.

If we don't make any normative statements, then the distinction
between using HTTP/2 euphemistically and strictly is less critical.
As do the requirements around multiple connections, which are, at
best, guidelines.  (As I tend to think all statements made in an RFC
are.)  I still think there is value in stating intent here.

---

From: Roland Zink <[email-masked]>
Date: Thu, 04 Sep 2014 10:26:13 +0200

> heard of a single use of it on the web.) 

Maybe you are happy about this: 
http://www.internetsociety.org/deploy360/blog/2014/07/a-hosting-provider-marketing-secure-hosting-with-ssl-dnssec-and-dane-tlsa/.

Roland

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 05 Sep 2014 02:24:39 +1200

On 4/09/2014 8:26 p.m., Roland Zink wrote:
>> The use of subjectAltName is intentionally exemplary for that
>> reason. The normative statements should still apply to DANE and
>> other related functions like pinning. But I think that it's
>> important to cover the most common cases in the example to help
>> avoid confusion where it matters most. (That is, until DANE is
>> more commonplace; I've not yet heard of a single use of it on the
>> web.)
> 
This browser plugin shows which sites are secured with DANE -
https://www.dnssec-validator.cz/. Its own site is secured.

Using it I was able to avoid numerous certificate warnings, exception
lists and click-throughs on Debian project websites
(https://www.debian.org/) amongst some other less popular sites.

Amos