Mark Nottingham <mnot@mnot.net>: (Wed Feb 10 05:31:11 2016)
> Hi Kari,
>
> I think Barry is about to start IETF LC on this, so if that happens, we'll just consider this LC feedback.
I see.
> It's a fair point. This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field on the Standards Track).
>
> What do others think?
>
https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1
| 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 the relationship
| between the origin and the alternative.
=>
| However, if "other.example.com"
| (or "www.example.com" on another port) is offered with the "h2c" protocol,
| the client cannot use it, because there is no mechanism in that protocol
| to establish the relationship between the origin and the alternative.
I think that this addition gives enough hint about that.
And probably drop "h2c" examples or add note (to near of examples):
| "h2c" protocol on example assumes that "reasonable assurance" (Section 2.1)
| is established elsewhere.
Or something like that.
/ Kari Hurtta
>> On 10 Feb 2016, at 5:28 am, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
>>
>>
>> Tricky
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1
>>
>> | 2.1. Host Authentication
>> |
>> |
>> | Clients MUST have reasonable assurances that the alternative service
>> | is under control of and valid for the whole origin.
>>
>> I have impression that on absence of other protocol, this is mean to
>> forbid use plain HTTP/2 (ie "h2c"), because there is no "reasonable
>> assurance".
>>
>> But is reader understanding that? There is examples which use "h2c".
>>
>> This does not give that
>>
>> | 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 the relationship
>> | between the origin and the alternative.
>>
>> Reader may think that there is "reasonable assurance" when hostname
>> is same.
>>
>> There is
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-9.1
>>
>> | 9.1. Changing Ports
>> |
>> |
>> | Using an alternative service implies accessing an origin's resources
>> | on an alternative port, at a minimum. An attacker that can inject
>> | alternative services and listen at the advertised port is therefore
>> | able to hijack an origin. On certain servers, it is normal for users
>> | to be able to control some personal pages available on a shared port,
>> | and also to accept to requests on less-privileged ports.
>>
>> But that part is confusing:
>>
>> | This risk is mitigated by the requirements in Section 2.1.
>>
>> When requirement is "reasonable assurance" I think that reader
>> is confused.
>>
>> "h2c" examples are
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3
>>
>> | The Alt-Svc field value can have multiple values:
>> |
>> | Alt-Svc: h2c=":8000", h2=":443"
>>
>>
>> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3.1
>>
>>
>> | HTTP/1.1 200 OK
>> | Content-Type: text/html
>> | Cache-Control: max-age=600
>> | Age: 30
>> | Alt-Svc: h2c=":8000"; ma=60
>>
>>
>> So my question is: Can reader understand this without
>> reading https://lists.w3.org/Archives/Public/ietf-http-wg/ ?
>>
>> ( Or without reading that other protocol RFC which
>> gives reasonable assurance. )
>>
>> / Kari Hurtta
>>
>
> --
> Mark Nottingham https://www.mnot.net/
>