Re: [Gen-art] Genart last call review of draft-ietf-httpbis-origin-frame-04

Brian, thanks for your review. Mark, thanks for your responses. I’ve entered a No Objection ballot.

Alissa

> On Nov 27, 2017, at 10:59 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Works for me.
> 
>    Brian
> 
> On 28/11/2017 13:33, Mark Nottingham wrote:
>> Thanks again. Please see:
>>  https://github.com/httpwg/http-extensions/commit/871a80d12aa
>> 
>> 
>>> On 27 Nov 2017, at 1:05 pm, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> On 27/11/2017 12:38, Mark Nottingham wrote:
>>>> Hi Brian,
>>>> 
>>>> Thanks for the review. Responses below.
>>>> 
>>>>> On 26 Nov 2017, at 2:44 pm, Brian Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>> [...]
>>>>> Minor Issues:
>>>>> -------------
>>>>> 
>>>>>> 2.1.  Syntax
>>>>> ...
>>>>>> Origin: An OPTIONAL sequence of characters ... that the
>>>>>> sender believes this connection is or could be authoritative for.
>>>>> 
>>>>> So, that implies that all data in the ORIGIN frame might be false.
>>>>> Doesn't that deserve a bit of a health warning at the beginning of the
>>>>> Security Considerations?
>>>> 
>>>> The first paragraph of SC is already:
>>>> 
>>>> """
>>>>  Clients that blindly trust the ORIGIN frame's contents will be
>>>>  vulnerable to a large number of attacks.  See Section 2.4 for mitigations.
>>>> """
>>>> 
>>>> What would you suggest?
>>>> 
>>>>> Also, using the word "believes" of a server
>>>>> is strange. How would the server acquire uncertain knowledge in the
>>>>> first place, and what algorithm would decide what it "believes"?
>>>> 
>>>> This is to emphasise that ORIGIN is advisory only -- it does not constitute proof (crypto does that).
>>> 
>>> Right. But I think it's the anthropomorphic choice of word that triggered me. If you said "that the sender asserts this connection is or could be authoritative for" I think I'd have nothing further to say, since it's clearly an assertion that needs to be checked.
>>> 
>>>> 
>>>>> Appendix A doesn't show any sign of a client checking whether an
>>>>> Origin-Entry is real.
>>>> 
>>>> As per Section 2.4, it isn't checked when the origin set is created or updated; it's checked when the value is used.
>>> 
>>> OK
>>> 
>>>> 
>>>> 
>>>>>> 2.3.  The Origin Set
>>>>> ...
>>>>>> o  Host: the value sent in Server Name Indication (SNI, [RFC6066]
>>>>>>   Section 3), converted to lower case
>>>>> 
>>>>> In that reference:
>>>>> 
>>>>>>> Literal IPv4 and IPv6 addresses are not permitted in "HostName".
>>>>> 
>>>>> Is that an intended or unintended restriction for the ORIGIN frame?
>>>>> In any case it should probably be mentioned explicitly to avoid confusion.
>>>>> (If IPv6 literals were allowed, they might be very convenient for server
>>>>> load balancing. But RFC6066 excludes that.)
>>>> 
>>>> Good catch. I don't think there's cause for confusion here (the text there isn't about what can go on the wire), but there is a corner case we haven't covered (when a client that supports SNI omits it because it's an IP literal). 
>>>> 
>>>> My inclination there is to say that the host is the SNI value or the server IP if SNI is missing; what do people think?
>>> 
>>>> From this reviewer's peanut gallery seat, that makes sense.
>>> 
>>>  Brian
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> --
>>>> Mark Nottingham   https://www.mnot.net/
>>>> 
>>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art