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

[Eric Rescorla <[e-mail]>]

On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A) <[e-mail]> wrote:

> 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.
>

Yes, but in order to have a useful countermeasure, that needs to be
mandatory, and yours is not.

-Ekr


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]>
> wrote:
>
> Hi,
> RTP payloads do not require usage of SRTP see RFC7201 and RFC7202
> Roni Even
>
> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: Tuesday, November 20, 2018 6:42 AM
> To: The IESG
> Cc: Daniel C. Burnett; [e-mail]; [e-mail]; Roni
> Even; [e-mail]; [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?
>
>