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/ > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
