Dear Brian, This is great. We will include the paragraph when we upload the new version soon.
Thank you so much! Richard On Tue, Feb 25, 2020 at 7:00 PM Brian Weis <bew.s...@gmail.com> wrote: > Hi Richard, > > The new text looks great to me. > > Thanks, > Brian > > On Feb 25, 2020, at 3:23 PM, Y. Richard Yang <y...@cs.yale.edu> wrote: > > > Dear Brian, > > Thank you so much for the review. Please see inline below. > > On Tue, Feb 25, 2020 at 12:56 AM Brian Weis via Datatracker < > nore...@ietf.org> wrote: > >> Reviewer: Brian Weis >> Review result: Ready >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> This document defines the ALTO Cost Calendar, an extension to the base >> Application-Layer Traffic Optimization (ALTO) protocol. Currently, the >> ALTO cost information service provides applications with guidance about >> current costs of a desired resource, but not for resources with a cost >> that >> changes dramatically over time. The ALTO Cost Calendar allows for >> specifying costs for varying time periods in the future. >> >> The extensions in this document are to the existing network flows, with >> policy defined in JSON. As such, additional security considerations are >> few. The well-written Security Considerations document does define a few >> considerations that come from announcing events that are expected to >> happen in the future. >> >> I have only one suggestion for additional text. The second >> paragraph on page 27 (draft -17) describes risks of a client using the >> calendaring information for their own selfish purposes. The suggested >> mitigation in the next paragraph is to limit the information “being >> leaked to malicious clients or third parties“ by authenticating clients >> with TLS. This strategy may thwart “third parties”, but it will not help >> in the case of “malicious clients” possessing valid credentials to >> authenticate. The threat here might be legitimate clients that have >> become subverted by an attacker and are now ‘bots’ being asked to >> participate in a DDoS attack. The calendar information would be valuable >> information for when to persecute a DDoS attack, and this should be >> noted here. >> > > This is an excellent point. The > compromised-but-still-appear-to-be-legitimate > is a quite reasonable setting. We have added the following paragraph, by > borrowing your excellent text above, right after the paragraph > "[RFC8446] specifies TLS 1.3 and writes in its section 1: ..." > > New paragraph: > > The operator should be should be cognizant that the preceding mechanisms > do not address all security risks. In particular, they will not help in > the case of “malicious clients” possessing valid credentials to > authenticate. The threat here can be that legitimate clients have > become subverted by an attacker and are now ‘bots’ being asked to > participate in a DDoS attack. The Calendar information would be valuable > information for when to persecute a DDoS attack. A mechanism such as > a monitoring system that detects abnormal behaviors may still be > needed." > > How does it look? > > Thanks a lot, > Richard > > > > > -- -- ===================================== | Y. Richard Yang <y...@cs.yale.edu> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
