Thanks Kai for clarification and proposed text @Samuel, would you like to confirm that the changes work for you or you have better suggested text. Thanks Samuel.
-Qin (on behalf of chairs) -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 发送时间: 2022年3月1日 16:15 收件人: Samuel Weiler <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected] 主题: Re: Secdir telechat review of draft-ietf-alto-path-vector-22 Hi Samuel, Thanks for the feedback. Please see our replies inline. Best, Kai > -----Original Messages----- > From: "Samuel Weiler via Datatracker" <[email protected]> > Sent Time: > 2022-02-26 05:38:53 (Saturday) > To: [email protected] > Cc: > [email protected], [email protected], [email protected] > > Subject: Secdir telechat review of > draft-ietf-alto-path-vector-22 > > Reviewer: Samuel Weiler > Review > result: Not Ready > > The security considerations text in this document > has changed markedly - and > multiple times - from when I reviewed it at > version -19. I'm > flagging this as > "Not Ready" mostly because I think it deserves another > set of eyes (e.g. the > ADs'). Thanks for the comment. Indeed we have revised the security section but these changes are to address the DISCUSS raised in the IEST reviews. The proposed texts are mainly based on our discussions with Roman [1]. [1] https://mailarchive.ietf.org/arch/msg/alto/PSjlTNhHKGdcjIHC8XYkxdulMzU/ > An intermediate version (-20) required the use of Digital Right Management > > (DRM). In -22, that's toned down to a recommendation. What other > non-DRM > technical solutions might help? Thanks for the comment. The requirement on DRM is toned down based on the IESG reviews [2]. Note that we have already instructed in the document that ALTO server/client should follow the guideline in RFC 7285 to protect the confidentiality in communication. The DRM approach in this document is used for the case where an authorized client, after it retrieves the information from the ALTO server, leaks the information to an unauthorized client. We feel this problem is not specific to path vector and the use of DRM is inherited from RFC 7285. [2] https://mailarchive.ietf.org/arch/msg/alto/Q6XiR0N9LZJxPjyJQvJEDaH_KyM/ > > It feels weird to have the the server being instructed do out-of-band things, > > e.g.: > > The ALTO server MUST carefully verify that the deployment > scenario satisfies the security assumptions of these methods > before > applying them to protect Path Vector services with sensitive > network > information. > > This sounds like a requirement for the operator of the server, which the > server > is in no position to enforce - and we're providing no technical > measure for > enforcing. > We agree. It should the operator of the ALTO server who verifies the conditions. How about we use the following texts: The ALTO service provider MUST carefully verify that the deployment scenario satisfies the security assumptions of these methods before applying them to protect Path Vector services with sensitive network information.</[email protected]> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
