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? -- 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. ---------------------------------------------------------------------- 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
