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

[Eric Rescorla <[e-mail]>]

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