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