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

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Nov 2018 20:42:01 -0800

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?

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 22 Nov 2018 11:24:12 +0000

Hi,
RTP payloads do not require usage of SRTP see RFC7201 and RFC7202
Roni Even

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

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

COMMENTS
S 12.
>      incapable of supporting it.

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Nov 2018 07:27:09 -0800

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) <[email-masked]> wrote:

> Cc: Daniel C. Burnett; [email-masked]; [email-masked]; Roni
> Even; [email-masked]; [email-masked]

---

From: "Roni Even (A)" <[email-masked]>
Date: Sun, 25 Nov 2018 05:40:59 +0000

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:[email-masked]]
Sent: Thursday, November 22, 2018 5:27 PM
To: Roni Even (A)
Cc: IESG; Daniel Burnett; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
RTP payloads do not require usage of SRTP see RFC7201 and RFC7202
Roni Even

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

COMMENTS
S 12.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2018 05:14:36 -0800

On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A) <[email-masked]> 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:[email-masked]]
> *Sent:* Thursday, November 22, 2018 5:27 PM
> *To:* Roni Even (A)
> *Cc:* IESG; Daniel Burnett; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Eric Rescorla's No Objection on
> draft-ietf-clue-signaling-14: (with COMMENT)
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Nov 2018 12:36:01 -0500

On 11/25/18 8:14 AM, Eric Rescorla wrote:
> 
> 
> On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A) <[email-masked] 
> <mailto:[email-masked]>> 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.
> 
> 

But one of the goals of clue is to be backward compatible with regular 
sip calls. If we impose constraints on the media over and above those 
required for regular sip calls then we lose that.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2018 11:29:34 -0800

> required for regular sip calls then we lose that.

ISTM that that's already not true for these media flows, because 4.4.1
requires them to
be inactive and you need to use an SCTP/DTLS control channel to negotiate
them.
What I'm saying is that those other flows should also have a consent check

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2018 14:48:33 -0500

On 11/25/18 2:29 PM, Eric Rescorla wrote:
> 
> 
> On Sun, Nov 25, 2018 at 9:35 AM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A)
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi,____
>      >
> be inactive and you need to use an SCTP/DTLS control channel to 
> negotiate them.

I was more concerned with the basic audio and/or video in the initial 
invite, before it is known whether the answerer supports clue. I don't 
have a particular problem with putting further restrictions on the clue 
controlled media.

	Thanks,
	Paul

---

From: "Rob Hanton (rohanse2)" <[email-masked]>
Date: Tue, 27 Nov 2018 09:55:15 +0000

We did have specific protections as mandantory to use in earlier drafts. From version 05:

   ... discussion of video hammer attack ...
   This attack can be prevented by ensuring that the media recipient
   intends to receive the media packets.  Because of the way that CLUE
   can increase the severity of this attack, as well as because of the
   general increased awareness of the need to secure critical payloads,
   a CLUE-capable device MUST secure all CLUE-controlled RTP "m" lines
   using SRTP [RFC3711], and MUST support and use key negotiation and
   receiver intent assurance via DTLS [RFC5763] on these "m" lines.  For
   backwards compatibility, this is not a mandatory requirement for non-
   CLUE-controlled "m" lines.

https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/05/?include_text=1

This was then changed in version 06 and onwards following the discussion at IETF 92 and later where there was opposition to making the use of DTLS/SRTP mandatory to use. If I recall the two major concerns people had were:
1) This prevents implementations using a superior mechanism should one be developed
2) This prevents two devices from the same vendor using some alternate means of authentication (potentially proprietary) that would reduce the need for DTLS/SRTP
(Minutes: https://datatracker.ietf.org/doc/minutes-92-clue/ )

So while everyone agreed that DTLS/SRTP should be mandatory to implement so it was always available, consensus ended up being removing the requirement to use DTLS/SRTP and instead having more generic language:

https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/?include_text=1

All drafts have always had an exception for non-CLUE-controlled lines for backwards compatibility.

Rob

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: 26 November 2018 19:49
To: Eric Rescorla <[email-masked]>
Cc: Roni Even <[email-masked]>; IESG <[email-masked]>; Daniel Burnett <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

On 11/25/18 2:29 PM, Eric Rescorla wrote:
> requires them to be inactive and you need to use an SCTP/DTLS control 
> channel to negotiate them.

I was more concerned with the basic audio and/or video in the initial invite, before it is known whether the answerer supports clue. I don't have a particular problem with putting further restrictions on the clue controlled media.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Nov 2018 07:11:16 -0800

On Tue, Nov 27, 2018 at 1:55 AM Rob Hanton (rohanse2) <[email-masked]>
wrote:

> This was then changed in version 06 and onwards following the discussion
> at IETF 92 and later where there was opposition to making the use of
> DTLS/SRTP mandatory to use. If I recall the two major concerns people had
> were:

I don't think this is a real objection, If a new mechanism should be
developed, then presumably it would also be documented in an RFC and we
could update this one.

2) This prevents two devices from the same vendor using some alternate
> means of authentication (potentially proprietary) that would reduce the
> need for DTLS/SRTP

It's not a matter of authentication. It's a matter of path validation. For
instance, if you were to have a situation where you had a cryptographic key
but it did not have an interactive handshake, that would not provide the
correct function. By contrast, ICE would.

So while everyone agreed that DTLS/SRTP should be mandatory to implement so
> it was always available, consensus ended up being removing the requirement
> to use DTLS/SRTP and instead having more generic language:
>

Yes, but the problem is that this doesn't require any kind of consent
validation at all, which creates an unacceptable amplification risk.

It seems to me that there are a number of options here:

1. Require DTLS-SRTP
2. Require ICE
3. Require *some* path-validating consent mechanism

However, just leaving the amplification attack does not seem OK.

-Ekr

> Cc: Roni Even <[email-masked]>; IESG <[email-masked]>; Daniel
> Burnett <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> invite, before it is known whether the answerer supports clue. I don't have
> a particular problem with putting further restrictions on the clue
> controlled media.
>
>         Thanks,
>         Paul
>