Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
Hi, Roman: Talking with Kai recently, he confirmed two issues raised in the Discuss (2023-10-23 for -17) Have been addressed. The latest version is v-21. Also he mentioned that his response to your email sometimes got filtered for some unknown reasons, I hope you have received Med's follow up and my followup. Thanks! -Qin (on behalf of chairs) -邮件原件- 发件人: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] 发送时间: 2023年12月7日 16:18 收件人: Roman Danyliw 抄送: The IESG ; alto-cha...@ietf.org; draft-ietf-alto-new-transp...@ietf.org; alto@ietf.org; kai...@scu.edu.cn 主题: RE: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) Hi Roman, This is a nudge to check whether the revised spec and the clarification provided by kai addressed your concerns. For convenience, the changes made since your review can be tracked here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-alto-new-transport-17&url2=draft-ietf-alto-new-transport-21&difftype=--html Thank you Med (Doc Shepherd) > -Message d'origine- > De : alto De la part de kai...@scu.edu.cn > Envoyé : dimanche 29 octobre 2023 13:27 À : Roman Danyliw > Cc : The IESG ; alto-cha...@ietf.org; > draft-ietf-alto- new-transp...@ietf.org; alto@ietf.org Objet : Re: > [alto] Roman Danyliw's Discuss on draft-ietf-alto-new- > transport-17: (with DISCUSS and COMMENT) > > Hi Roman, > > I hope you are OK with our responses to your DISCUSS points. This is > the follow-up update regarding your comments. > > First, for the comment on Digest authentication, we agree that this is > a fair request as RFC 7285 says Digest authentication is mandatory. An > example using Digest authentication is added in Sec 6.3. > > For the comment on mandating RFC 9325, I am a bit hesitated to do so. > First, this seems a bit repetitive as Section 15.1.2 in RFC 7285 > already says > > "Software engineers developing and service providers deploying ALTO >should make themselves familiar with possibly updated standards >documents as well as up-to-date Best Current Practices on > configuring >HTTP over TLS." > > Second, RFC 9325 seems to be applicable to any protocol building on > top of TLS, not specific to ALTO. It is also applicable to any > extension to ALTO. It feels a bit weird to add something that is > broader than the scope of the extension specified in the document, > especially when it does not require specific attentions to the TLS > layer. > > We could certainly add a sentence saying that developers of this > extensions should follow RFC 9325 if you think this is really > important. Otherwise we intend to not include the discussion on TLS. > > Best, > Kai > > > -Original Messages- > > From: kai...@scu.edu.cn > > Send time:Wednesday, 10/25/2023 17:57:00 > > To: "Roman Danyliw" > > Cc: "The IESG" , alto-cha...@ietf.org, > > draft-ietf-alto-new-transp...@ietf.org, alto@ietf.org > > Subject: Re: [alto] Roman Danyliw's Discuss on > > draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) > > > > Hi Roman, > > > > Thanks for the review. Please see inline. > > > > Best, > > Kai > > > > > > > -----Original Messages----- > > > From: "Roman Danyliw via Datatracker" Send > > > time:Tuesday, 10/24/2023 10:40:46 > > > To: "The IESG" > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > po > > > > sitions%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb767734f0 > > > > 9704481993708dbd87a6810%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > > > > C638341792466819799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > > > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mqO > > > DvELZY%2BRRd%2BP5DXCADt80aHoBoZ4mMHrxf8sspPw%3D&
Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
Hi Roman, This is a nudge to check whether the revised spec and the clarification provided by kai addressed your concerns. For convenience, the changes made since your review can be tracked here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-alto-new-transport-17&url2=draft-ietf-alto-new-transport-21&difftype=--html Thank you Med (Doc Shepherd) > -Message d'origine- > De : alto De la part de kai...@scu.edu.cn > Envoyé : dimanche 29 octobre 2023 13:27 > À : Roman Danyliw > Cc : The IESG ; alto-cha...@ietf.org; draft-ietf-alto- > new-transp...@ietf.org; alto@ietf.org > Objet : Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new- > transport-17: (with DISCUSS and COMMENT) > > Hi Roman, > > I hope you are OK with our responses to your DISCUSS points. This is > the follow-up update regarding your comments. > > First, for the comment on Digest authentication, we agree that this is > a fair request as RFC 7285 says Digest authentication is mandatory. An > example using Digest authentication is added in Sec 6.3. > > For the comment on mandating RFC 9325, I am a bit hesitated to do so. > First, this seems a bit repetitive as Section 15.1.2 in RFC 7285 > already says > > "Software engineers developing and service providers deploying ALTO >should make themselves familiar with possibly updated standards >documents as well as up-to-date Best Current Practices on > configuring >HTTP over TLS." > > Second, RFC 9325 seems to be applicable to any protocol building on > top of TLS, not specific to ALTO. It is also applicable to any > extension to ALTO. It feels a bit weird to add something that is > broader than the scope of the extension specified in the document, > especially when it does not require specific attentions to the TLS > layer. > > We could certainly add a sentence saying that developers of this > extensions should follow RFC 9325 if you think this is really > important. Otherwise we intend to not include the discussion on TLS. > > Best, > Kai > > > -Original Messages- > > From: kai...@scu.edu.cn > > Send time:Wednesday, 10/25/2023 17:57:00 > > To: "Roman Danyliw" > > Cc: "The IESG" , alto-cha...@ietf.org, > > draft-ietf-alto-new-transp...@ietf.org, alto@ietf.org > > Subject: Re: [alto] Roman Danyliw's Discuss on > > draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) > > > > Hi Roman, > > > > Thanks for the review. Please see inline. > > > > Best, > > Kai > > > > > > > -----Original Messages- > > > From: "Roman Danyliw via Datatracker" Send > > > time:Tuesday, 10/24/2023 10:40:46 > > > To: "The IESG" > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > po > > > > sitions%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Cb767734f0 > > > > 9704481993708dbd87a6810%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > > > > C638341792466819799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > > > > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mqO > > > DvELZY%2BRRd%2BP5DXCADt80aHoBoZ4mMHrxf8sspPw%3D&reserved=0 > > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-alto-new- > transport%2F&data=05% > > > > 7C01%7Cmohamed.boucadair%40orange.com%7Cb767734f09704481993708dbd87a > > > > 6810%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638341792466819799 > > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > > > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
Hi Roman, I hope you are OK with our responses to your DISCUSS points. This is the follow-up update regarding your comments. First, for the comment on Digest authentication, we agree that this is a fair request as RFC 7285 says Digest authentication is mandatory. An example using Digest authentication is added in Sec 6.3. For the comment on mandating RFC 9325, I am a bit hesitated to do so. First, this seems a bit repetitive as Section 15.1.2 in RFC 7285 already says "Software engineers developing and service providers deploying ALTO should make themselves familiar with possibly updated standards documents as well as up-to-date Best Current Practices on configuring HTTP over TLS." Second, RFC 9325 seems to be applicable to any protocol building on top of TLS, not specific to ALTO. It is also applicable to any extension to ALTO. It feels a bit weird to add something that is broader than the scope of the extension specified in the document, especially when it does not require specific attentions to the TLS layer. We could certainly add a sentence saying that developers of this extensions should follow RFC 9325 if you think this is really important. Otherwise we intend to not include the discussion on TLS. Best, Kai > -Original Messages- > From: kai...@scu.edu.cn > Send time:Wednesday, 10/25/2023 17:57:00 > To: "Roman Danyliw" > Cc: "The IESG" , alto-cha...@ietf.org, > draft-ietf-alto-new-transp...@ietf.org, alto@ietf.org > Subject: Re: [alto] Roman Danyliw's Discuss on > draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) > > Hi Roman, > > Thanks for the review. Please see inline. > > Best, > Kai > > > > -Original Messages- > > From: "Roman Danyliw via Datatracker" > > Send time:Tuesday, 10/24/2023 10:40:46 > > To: "The IESG" > > 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 s
Re: [alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
Hi Roman, Thanks for the review. Please see inline. Best, Kai > -Original Messages- > From: "Roman Danyliw via Datatracker" > Send time:Tuesday, 10/24/2023 10:40:46 > To: "The IESG" > 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
[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? -- 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
