Re: [MEDIACTRL] <encryption> support
"Roni Even" <ron.even.tlv@gmail.com> Wed, 19 December 2012 13:08 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5421F86F0 for <mediactrl@ietfa.amsl.com>; Wed, 19 Dec 2012 05:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwWWT5xRtARN for <mediactrl@ietfa.amsl.com>; Wed, 19 Dec 2012 05:08:30 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 744F221F8696 for <mediactrl@ietf.org>; Wed, 19 Dec 2012 05:08:30 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id d49so1040294eek.32 for <mediactrl@ietf.org>; Wed, 19 Dec 2012 05:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=uv/ecAp3LiTHc2iZBBU7hfVWLWLXiKu0Zoaygln871k=; b=z3ireD4hYlEmQMy8+a6yzChgGpXn72RstI6viEPSCEBzCRYG4kKCjfAPJ7XcgYzfRh ELom+lXKmGr++SJ90zo4hE53Lej1wvaIadEO7AH6cn6teCRLZz8VBgAsQ0V/5YeZgxpU mjfv7ZR8IUw9aR88pISWXXSTAnZKAOD9MVgJTtb8fcx8o3tMnzBQfxBOCPy2qlEJI77Y 1Ip8D5BQBl36S0X+cTAXKbOw11SbTWyiEahpdlo3noZauW350QVm2u8M9hqnbb1Yp/OV M7nhZ7f9llCeggOtNm/pHIHXqhny6cvwz/RUr7vbp9jZ01qnntKtTLCPUpltyUqjMWv0 umuw==
X-Received: by 10.14.1.195 with SMTP id 43mr14194802eed.31.1355922509509; Wed, 19 Dec 2012 05:08:29 -0800 (PST)
Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id v46sm9166025eep.1.2012.12.19.05.08.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 05:08:26 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Eric Burger' <eburger@standardstrack.com>, mediactrl@ietf.org
References: <B3EC21B7-1539-49C1-BC17-9771025B0C54@standardstrack.com>
In-Reply-To: <B3EC21B7-1539-49C1-BC17-9771025B0C54@standardstrack.com>
Date: Wed, 19 Dec 2012 15:05:39 +0200
Message-ID: <03ec01cddde9$8ddf6a00$a99e3e00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLd1kKwiExmI4d6sQqJgvzoitKCu5YAJG8A
Content-Language: en-us
Subject: Re: [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: Wed, 19 Dec 2012 13:08:31 -0000
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: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On Behalf Of Eric Burger Sent: 13 December, 2012 11:55 PM To: mediactrl@ietf.org 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. 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?
- [MEDIACTRL] <encryption> support Eric Burger
- Re: [MEDIACTRL] <encryption> support Chris Boulton
- Re: [MEDIACTRL] <encryption> support Lorenzo Miniero
- Re: [MEDIACTRL] <encryption> support Chris Boulton
- Re: [MEDIACTRL] <encryption> support Tobia Castaldi UniNa
- Re: [MEDIACTRL] <encryption> support Simon Pietro Romano
- Re: [MEDIACTRL] <encryption> support Scott McGlashan
- Re: [MEDIACTRL] <encryption> support Roni Even
- Re: [MEDIACTRL] <encryption> support Eric Burger