Re: [secdir] Secdir last call review of draft-ietf-alto-cost-calendar-17

["Y. Richard Yang" <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Richard,
>
> The new text looks great to me.
>
> Thanks,
> Brian
>
> On Feb 25, 2020, at 3:23 PM, Y. Richard Yang <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================