Hi Roman, Thanks for the review. Please see inline.
Best, Kai > -----Original Messages----- > From: "Roman Danyliw via Datatracker" <nore...@ietf.org> > Send time:Tuesday, 10/24/2023 10:40:46 > To: "The IESG" <i...@ietf.org> > Cc: alto-cha...@ietf.org, draft-ietf-alto-new-transp...@ietf.org, > alto@ietf.org > Subject: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: > (with DISCUSS and COMMENT) > > Roman Danyliw has entered the following ballot position for > draft-ietf-alto-new-transport-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 6.2. Construction of the “tips-view-uri”. > > -- Under what circumstances would it be appropriate to use http (instead of > https) for the tips-view-uri for this new protocol mechanism? Why is http > needed? Could https be the only option? I appreciate that there is history > of > an http URL from RFC7285 published in 2014, but has field experience continue > to dictate a need for this insecure approach for an entirely new service? If > it is needed would there be a away to express a preference for secure > transport? > [KAI] One reason I can think of to keep http is to allow caching of incremental updates (whose uri is based on the tips-view-uir) for a given resource whose content is intended to be publicly accessible, which could happen if the server is hosted by the ISP and a cost map is intended to be accessible by all its users. How about we add the following sentence in sec 6.2: An ALTO server SHOULD always use "https" unless the ALTO resource is intended to be publicly accessible and does not raise any security concerns. > -- Is there any underlying assumption in how “tips-view-path” is constructed? > I > asked because Section 9.3 says “An outside party that can read the TIPS > response or that can observe TIPS requests can obtain the TIPS view URI and > use > that to send fraudulent ‘DELETE’ requests thus disabling the service for the > valid ALTO client. This can be avoided by encrypting the requests and > responses (Section 15 of [RFC7285]).” Observing the tips-view-uri is one way > to spoof the URI, but what if it could be guessed? Is there an assumption > that > a unguessable random string is part of the path? As far as I can find, no > text > explicitly says that, although the examples imply it. If the string is > guessable being encrypted doesn’t help but using some kind of authentication > would. > > [KAI] In -17, the fraudulent 'DELETE' issue no long exists as we now require the server to close of TIPS views, as suggested by the HTTPDIR reviewer and the AD. I think that would address this issue. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Donald Eastlake for the SECDIR review. > > ** Section 6.3. The example in Figure 10 describes Basic Auth. Section 8.3.5 > of RFC7295 notes that Digest Auth is MTI. Recommend using that instead. > > ** Section 9. > The security considerations (Section 15 of [RFC7285]) of the base > protocol fully apply to this extension. For example, the same > authenticity and integrity considerations (Section 15.1 of [RFC7285]) > still fully apply; > > Since ALTO TIPS is a new protocol mechanism is it possible to improve on the > TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)? Specifically, can > RFC9325 be mandated? > > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
