- From: Alissa Cooper <alissa@cooperw.in>
- Date: Tue, 9 Jan 2018 12:25:32 -0500
- To: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, gen-art <gen-art@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Tuesday, 9 January 2018 17:25:59 UTC