[MEDIACTRL] <encryption> support

Eric Burger <eburger@standardstrack.com> Thu, 13 December 2012 21:55 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 391B021F8BE8 for <mediactrl@ietfa.amsl.com>; Thu, 13 Dec 2012 13:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.949
X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id d-dIkeEbOpCW for <mediactrl@ietfa.amsl.com>; Thu, 13 Dec 2012 13:55:15 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com []) by ietfa.amsl.com (Postfix) with ESMTP id B8B7921F8BE7 for <mediactrl@ietf.org>; Thu, 13 Dec 2012 13:55:15 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([]:63195 helo=[]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1TjGkL-00047D-Dq; Thu, 13 Dec 2012 13:55:14 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary=Apple-Mail-210--828608470; protocol="application/pkcs7-signature"; micalg=sha1
Date: Thu, 13 Dec 2012 16:55:13 -0500
To: mediactrl@ietf.org
Message-Id: <B3EC21B7-1539-49C1-BC17-9771025B0C54@standardstrack.com>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
Subject: [MEDIACTRL] <encryption> support
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2012 21:55:16 -0000

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