- From: Brian E Carpenter <brian.e.carpenter@gmail.com>
- Date: Tue, 28 Nov 2017 03:59:31 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: gen-art@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
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/ > >
Received on Tuesday, 28 November 2017 10:26:56 UTC