Re: #492: Alt-Svc header host restriction

On 2014-06-12 19:51, Martin Thomson wrote:
> On 12 June 2014 10:25, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> p.s., I think we agreed to lift the restriction on other host names
>>> and move that to -encryption.
>>
>> a) the restriction is gone, no? b) -encryption?
>
> =b.  I think that the key here is that:
>
> The key is that the server that you end up on needs to be determined
> to be authoritative by the means described in the definition of the
> URL you are resolving.
>
> Thus, for http: URIs, the server you end up on needs to use DNS name
> resolution and IP routing based on the host name that is in the URI.
>
> For https: URIs, the server you end up on needs to present a
> certificate that is valid for the host name that is in the URI.
>
> This is a property of HTTP/1.1 that we don't want to change:
> https://tools.ietf.org/html/rfc7230#section-9.1

Ok, we currently have 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#host_auth>:

> 2.1 Host Authentication
>
> Clients MUST NOT use alternative services with a host other than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin.
>
> For example, if the origin's host is "www.example.com" and an alternative is offered on "other.example.com" with the "h2" protocol, and the certificate offered is valid for "www.example.com", the client can use the alternative. However, if "other.example.com" is offered with the "h2c" protocol, the client cannot use it, because there is no mechanism in that protocol to establish strong server authentication.
>
> Furthermore, this means that the HTTP Host header field and the SNI information provided in TLS by the client will be that of the origin, not the alternative.

So it seems that this needs a rewrite.

> ...

Best regards, Julian

Received on Thursday, 12 June 2014 18:05:20 UTC