Subject: [MEDIACTRL] <encryption> support

From: Eric Burger <[email-masked]>
Date: Thu, 13 Dec 2012 16:55:13 -0500

Section 5.1.5.21 of http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the keying mechanism.  However, as numerous ADs have pointed out, there is no IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers principally but others with skin in the game. Specifically, what if we said there is one and only one official, supported keying mechanism, namely DTLS-SRTP?  While it is true that today most SIP SRTP implementations are SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server supports
   DTLS-SRTP [RFC 5763].

   The <encryption> element has no attributes.

Anyone want to see something different?

---

From: Chris Boulton <[email-masked]>
Date: Fri, 14 Dec 2012 12:04:54 +0000

+1 from me.

On 13/12/2012 21:55, Eric Burger wrote:
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 14 Dec 2012 13:15:26 +0100

On Fri, 14 Dec 2012 12:04:54 +0000

> +1 from me.

+1 from me as well,

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Chris Boulton <[email-masked]>
Date: Fri, 14 Dec 2012 12:01:52 +0000

+1 from me.

---

From: Tobia Castaldi UniNa <[email-masked]>
Date: Fri, 14 Dec 2012 17:25:07 +0100

> Chris Boulton <[email-masked]> wrote:

+1
from me too

T.

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 14 Dec 2012 17:34:08 +0100

One more from my side.

Simon

>>> Anyone want to see something different?

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Scott McGlashan <[email-masked]>
Date: Tue, 18 Dec 2012 10:27:58 +0000

+1 from me too.

Scott

On 14 Dec 2012, at 12:04, Chris Boulton wrote:

> NS-Technologies

---

From: "Roni Even" <[email-masked]>
Date: Wed, 19 Dec 2012 15:05:39 +0200

Hi,
I am not happy and would have liked to see also SDES maybe define two values
for the <encryption> element. Note that encryption is specified also in
other sections for the client and mixer so the definition should be
consistent.
The IMTC defined a security profile for video conference end points with
both SDES (used by current systems) and DTLS for new systems.
I will not object  to just having DTLS.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
Sent: 13 December, 2012 11:55 PM
To: [email-masked]
Subject: [MEDIACTRL] <encryption> support

Section 5.1.5.21 of
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an
indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the
keying mechanism.  However, as numerous ADs have pointed out, there is no
IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers
principally but others with skin in the game. Specifically, what if we said
there is one and only one official, supported keying mechanism, namely
DTLS-SRTP?  While it is true that today most SIP SRTP implementations are
SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will
also be the only keying mechanism for RTCWEB.

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server
supports
   DTLS-SRTP [RFC 5763].