Subject: [clue] Media security in draft-ietf-clue-framework-23

From: "Roni Even" <[email-masked]>
Date: Thu, 5 Nov 2015 02:33:41 +0200

Hi,

The current text in the document is:

"In addition, the media is based on RTP and thus existing RTP security
mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported."

At the CLUE session in the chair presentation slide we suggested

"In addition, the media is based on RTP and thus existing RTP security
mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported and SHOULD
be used. If media is protected by other means [RFC7201], then DTLS/SRTP does
not need to be used."

This text means that the RTP channel MUST be secure by some means but in
order to better clarify it I suggest that we change it to:

"In addition, the media is based on RTP and MUST be secure. Existing RTP
security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported and
SHOULD be used.  DTLS/SRTP does not need to be used when RTP media is
secured by other means  see [RFC7201] and [RFC7202]"

Does this looks OK?

Thanks

Roni

---

From: Daniel Burnett <[email-masked]>
Date: Wed, 4 Nov 2015 20:24:03 -0500

On Wed, Nov 4, 2015 at 7:33 PM, Roni Even <[email-masked]> wrote:

> “In addition, the media is based on RTP and thus existing RTP security
> mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.”
>
>
>
> “In addition, the media is based on RTP and thus existing RTP security
> be used. If media is protected by other means [RFC7201], then DTLS/SRTP
> does not need to be used.”
>
>
>
> “In addition, the media is based on RTP and MUST be secure. Existing RTP
> security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported
> and SHOULD be used.  DTLS/SRTP does not need to be used when RTP media is
> secured by other means  see [RFC7201] and [RFC7202]”
>

Why don't we just be more explicit?  How about

"In addition, the media MUST be secured.  DTLS/SRTP MUST be supported and
SHOULD be used unless the media, which is based on RTP, is secured by one
of the other means documented in [RFC7201]."

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Nov 2015 11:17:53 +0900

> On Nov 5, 2015, at 10:24 AM, Daniel Burnett <[email-masked]> wrote:
> 
> 
> 
> On Wed, Nov 4, 2015 at 7:33 PM, Roni Even <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> “In addition, the media is based on RTP and thus existing RTP security   mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.”
> 
>  
> 
> “In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported and SHOULD be used. If media is protected by other means [RFC7201], then DTLS/SRTP does not need to be used.”
> 
>  
> 
> This text means that the RTP channel MUST be secure by some means but in order to better clarify it I suggest that we change it to:
> 
>  
> 
> “In addition, the media is based on RTP and MUST be secure. Existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported and SHOULD be used.  DTLS/SRTP does not need to be used when RTP media is secured by other means  see [RFC7201] and [RFC7202]”
> 
> 
> "In addition, the media MUST be secured.  DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by one of the other means documented in [RFC7201].”

WFM
Alissa

---

From: "Roni Even" <[email-masked]>
Date: Thu, 5 Nov 2015 04:23:30 +0200

Hi,

"In addition, the media MUST be secured.  DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means see [RFC7201] [RFC7202]."

The reason for this text about RFC7201 is because it is informational RFC and provides examples and not all the options.

Roni

From: Daniel Burnett [mailto:[email-masked]] 
Sent: Thursday, November 05, 2015 3:24 AM
To: Roni Even
Cc: Duckworth, Mark; Paul Kyzivat; [email-masked]; Alissa Cooper
Subject: Re: Media security in draft-ietf-clue-framework-23

Hi,

"In addition, the media MUST be secured.  DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by one of the other means documented in [RFC7201]."

Does this looks OK?

Thanks

Roni

---

From: Daniel Burnett <[email-masked]>
Date: Thu, 5 Nov 2015 18:50:09 -0500

On Wed, Nov 4, 2015 at 9:23 PM, Roni Even <[email-masked]> wrote:

> SHOULD be used unless the media, which is based on RTP, is secured by other
> means see [RFC7201] [RFC7202]."
>
>
>
> The reason for this text about RFC7201 is because it is informational RFC
> and provides examples and not all the options.
>
> I understand your concern.  However, when we get the security review I
expect that less strict text along the lines of "secured by other means
such as those documented in [RFC7201]" will cause a DISCUSS because you
have not spelled out the security properties you are trying to obtain.  Is
there a more specific pointer into 7201 or 7202 that you could use that
indicates what security properties are intended when we say that the media
MUST be secured?  In other words, secured against what or whom?  Is it good
enough for me to just declare that my media is secure because I think it is?

>
>
> Roni
>
>
>
>
>
> *From:* Daniel Burnett [mailto:[email-masked]]
> *Sent:* Thursday, November 05, 2015 3:24 AM
> *To:* Roni Even
> *Cc:* Duckworth, Mark; Paul Kyzivat; [email-masked]; Alissa Cooper
> *Subject:* Re: Media security in draft-ietf-clue-framework-23
>
>
>
>
>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 6 Nov 2015 09:15:06 +0900

> On Nov 5, 2015, at 11:23 AM, Roni Even <[email-masked]> wrote:
> 
> Hi,
>  
> 
> "In addition, the media MUST be secured.  DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means see [RFC7201] [RFC7202].”
> 

WFM. I would put the last bit in parentheses — (see [RFC7201][RFC7202]).

For avoidance of doubt, the additional change also needed in draft-ietf-clue-signaling is in this sentence in Section 12:

All CLUE-
   controlled RTP "m" lines must be secured and implemented using
   mechanisms such as SRTP [RFC3711 <https://tools.ietf.org/html/rfc3711>]; no specific security mechanisms
   are made mandatory to use due to the issues addressed in [RFC7202 <https://tools.ietf.org/html/rfc7202>].

s/must/MUST/
> From: Daniel Burnett [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Duckworth, Mark; Paul Kyzivat; [email-masked] <mailto:[email-masked]>; Alissa Cooper

---

From: Daniel Burnett <[email-masked]>
Date: Thu, 5 Nov 2015 19:27:01 -0500

On Thu, Nov 5, 2015 at 7:15 PM, Alissa Cooper <[email-masked]> wrote:

> means see [RFC7201] [RFC7202].”
>
>
> For avoidance of doubt, the additional change also needed in
> draft-ietf-clue-signaling is in this sentence in Section 12:
>
> All CLUE-

If Alissa thinks this will pass IESG review, I have no further objections.

> *From:* Daniel Burnett [mailto:[email-masked]
> <[email-masked]>]

---

From: Robert Hansen <[email-masked]>
Date: Fri, 06 Nov 2015 17:50:51 +0000

On 06/11/15 00:27, Daniel Burnett wrote:
>
>
> On Thu, Nov 5, 2015 at 7:15 PM, Alissa Cooper <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     On Nov 5, 2015, at 11:23 AM, Roni Even <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     "In addition, the media MUST be secured.  DTLS/SRTP MUST be
>>     supported and SHOULD be used unless the media, which is based on
>>     RTP, is secured by other means see [RFC7201] [RFC7202].”
>>
>
Will ensure I change the signaling text accordingly in the next revision.

Rob

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 11 Nov 2015 14:43:51 -0800

I will initiate IETF LC when Mark posts the rev.

Alissa

> On Nov 5, 2015, at 4:27 PM, Daniel Burnett <[email-masked]> wrote:
> 
> 
> 
> On Thu, Nov 5, 2015 at 7:15 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Nov 5, 2015, at 11:23 AM, Roni Even <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>  
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 12 Nov 2015 07:42:59 -0800

I submitted draft -24 with the security updates.  Please review to make sure I got it right this time.
Mark

From: Alissa Cooper [mailto:[email-masked]]
Sent: Wednesday, November 11, 2015 5:44 PM
To: Daniel Burnett
Cc: Roni Even; Duckworth, Mark; Paul Kyzivat; [email-masked]
Subject: Re: Media security in draft-ietf-clue-framework-23

Alissa

On Nov 5, 2015, at 4:27 PM, Daniel Burnett <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 5, 2015 at 7:15 PM, Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 5, 2015, at 11:23 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

All CLUE-

   mechanisms such as SRTP [RFC3711<https://tools.ietf.org/html/rfc3711>]; no specific security mechanisms

   are made mandatory to use due to the issues addressed in [RFC7202<https://tools.ietf.org/html/rfc7202>].

s/must/MUST/

Roni

From: Daniel Burnett [mailto:[email-masked]]
Sent: Thursday, November 05, 2015 3:24 AM
To: Roni Even
Cc: Duckworth, Mark; Paul Kyzivat; [email-masked]<mailto:[email-masked]>; Alissa Cooper
Subject: Re: Media security in draft-ietf-clue-framework-23

On Wed, Nov 4, 2015 at 7:33 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
The current text in the document is:
“In addition, the media is based on RTP and thus existing RTP security   mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.”

Does this looks OK?

Thanks
Roni