- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 28 Nov 2017 11:33:27 +1100
- To: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Cc: gen-art@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Tuesday, 28 November 2017 00:33:58 UTC