Re: [clue] Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

["Roni Even (A)" <[e-mail]>]

Hi,
The point that is made that in general CLUE is similar to no CLUE RTP media calls. The difference is that since the EP may open more than one RTP video channel there is a greater risk of sending more media to the victim. RFC7201 discuss the options to secure the media and this holds for this case too.

Roni

From: Eric Rescorla [mailto:[e-mail]]
Sent: Thursday, November 22, 2018 5:27 PM
To: Roni Even (A)
Cc: IESG; Daniel Burnett; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

The problem is that this is in the context of amplification attacks

   Beyond the need to secure the constituent protocols, the use of CLUE
   does impose additional security concerns.  One area of increased risk
   involves the potential for a malicious party to subvert a CLUE-
   capable device to attack a third party by driving large volumes of
   media (particularly video) traffic at them by establishing a
   connection to the CLUE-capable device and directing the media to the
   victim.  While this is a risk for all media devices, a CLUE-capable
   device may allow the attacker to configure multiple media streams to
   be sent, significantly increasing the volume of traffic directed at
   the victim.

   This attack can be prevented by ensuring that the media recipient
   intends to receive the media packets.  As such all CLUE-capable
   devices MUST support key negotiation and receiver intent assurance
   via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.

And so if you don't require DTLS-SRTP or ICE than in fact there is no amplification
attack defense.

-Ekr


On Thu, Nov 22, 2018 at 3:24 AM Roni Even (A) <[e-mail]<mailto:[e-mail]>> wrote:
Hi,
RTP payloads do not require usage of SRTP see RFC7201 and RFC7202
Roni Even

-----Original Message-----
From: Eric Rescorla [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, November 20, 2018 6:42 AM
To: The IESG
Cc: Daniel C. Burnett; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Roni Even; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-clue-signaling-14: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4099



COMMENTS
S 12.
>      via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
>      controlled RTP "m" lines must be secured and implemented using
>      mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
>      not to require the use of SRTP to secure legacy (non-CLUE-controlled)
>      media for backwards compatibility with older SIP clients that are
>      incapable of supporting it.

It seems like you need more than support, you also need to require the use of DTLS-SRTP, no?