Re: h2 requirements on authoritative responses

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/09/2014 12:22 p.m., Martin Thomson wrote:
> On 2 September 2014 16:55, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> 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.

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?


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

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

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.


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

+1.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUBnFwAAoJELJo5wb/XPRjpd8H/REx5/qbjQGgtijNj1HJx9Dy
9MX3bPhM3Tc3DeaD7BTT5a4LAji4dVzGLWH0+itAssthp6eIyMqeabS50xSpr+OI
HxlLSPUJKM74GgosE5Jz/cDbHFMYis+FJTRPJVYp7I1EHZhAZA43ZnuxZieMyn4X
O/n27a6MYeFaZPw7ZayOrk5mfo9Lltq7jV7H3/jTWk6ufDnfZoM5wEX8JB5ObXiK
IfqKLfYfVNWBLPb3OqJKYw5yaDQCC4xfhTGgpKD+3yT5nXTjpEn9QBD1IP4MjBvy
p2KEWw3tew3nQrKB0LXaqKcrewiyqkmXxDXefhl8AxOkjvx/ltFpQ0oNFpI2dHY=
=g4Ud
-----END PGP SIGNATURE-----

Received on Wednesday, 3 September 2014 01:57:20 UTC