Re: [rtcweb] Consensus call regarding media security

Roman Shpount <roman@telurix.com> Wed, 28 March 2012 16:15 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CD921E8260 for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 09:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.822
X-Spam-Level:
X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtOsqreFxLxG for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 391E821E808F for <rtcweb@ietf.org>; Wed, 28 Mar 2012 09:15:16 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so938471ggm.31 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 09:15:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=chqJF1Fcgygx0fFeJjeow14oO7XpZiP6uf0N1Q3jS5g=; b=L8f4HTxO4lRNoYaK/HVGTKhNzFLPg8+NRXMd9MEaJptmee1ke0U/eSl/ggJWTaQhFl jm1uZYkikESUAI+BbvN8KgJWrncC/JFFYKBnFh16JPT7VpKM6kWEwiHw2FNOaqNLXIj/ oDtZppJEHc6Nvkp1pUYBMnzpHPsjI3KHaEHtgendXxL7LjgwPkpwWzqFQoyEHExWuup3 m/fx3uk2jaU/v7aVq0THiEqJzKx1x50FwKme2rEZVuMJp9Oxjp9VfbzIDGnMOqpqBRnz ImdMhzewckqvULZwNr3HCmLUlb1SdLYr7ZgBr/ah62l0JkAA6WW6xPfqkrupK4rAjB/i O+Cg==
Received: by 10.236.145.34 with SMTP id o22mr1743215yhj.7.1332951315828; Wed, 28 Mar 2012 09:15:15 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id t43sm9025479yht.11.2012.03.28.09.15.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 09:15:15 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so978081vcb.31 for <rtcweb@ietf.org>; Wed, 28 Mar 2012 09:15:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.58.197 with SMTP id i5mr7809964vch.38.1332951310413; Wed, 28 Mar 2012 09:15:10 -0700 (PDT)
Received: by 10.220.192.195 with HTTP; Wed, 28 Mar 2012 09:15:10 -0700 (PDT)
In-Reply-To: <4F733492.9040601@alcatel-lucent.com>
References: <4F732531.2030208@ericsson.com> <CAD5OKxs6NHha2egNSTumEaHYJ0bB6qu_nfshmBM6dntx2n49HQ@mail.gmail.com> <4F733492.9040601@alcatel-lucent.com>
Date: Wed, 28 Mar 2012 12:15:10 -0400
Message-ID: <CAD5OKxv8PhhwmjaDHqet1NBmJ+8ndKBc7p7fjC2vogE1wXT=sg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: igor.faynberg@alcatel-lucent.com
Content-Type: multipart/alternative; boundary="0023544477cd5c31a904bc4fe9c0"
X-Gm-Message-State: ALoCoQkHfJN8dTuQY6xShSO/BN3eBueb2uH32zJiLA5nOhWxxHnnopkIp76n7sWU/43lRs1ZaHIc
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus call regarding media security
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 16:15:17 -0000

Igor,

I could not attend the meeting today, but I am responding to the call of
consent on the list, that did not mention that or any other conditions on
SRTP encryption support. Does it also mean that the call can be established
using plain RTP, or is DTLS handshake, even in order to setup NULL
encruption, is still a requirement? If DTLS handshake is a requirement, I
still would object to it, since this will require an extra implementation
and interop step in anything communicating with WebRTC.

On the related note, where is SRTP profile with NULL encoding defined? I
have seen quite a few SRTP implementations but not a single one of them
supported NULL codec in any of its profiles.  Also, we should be very
careful not to support NULL encoding unless it is specifically enabled in
API. Even though I do want to support unencrypted media, I do not want
anything that allows to bid down from encrypted to unencrypted connection,
for instance during DTLS negotiation, unless specifically enabled.
_____________
Roman Shpount


On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg <
igor.faynberg@alcatel-lucent.com> wrote:

> **
> Roman,
>
> I think there is a misunderstanding (I assume you did not attend the
> meeting today).  It has been clarified that SRTP allows the NULL encryption
> algorithm, and that this option will be available.
>
> Igor
>
>
> On 3/28/2012 11:49 AM, Roman Shpount wrote:
>
> As I have mentioned before on this list I am strongly against making SRTP
> protection for RTP a requirement. I think this is an unnecessary
> requirement that serves little real purpose except feeding into some
> marketing message that most of the WebRTC users would not care about.
> Unless use of identity is also a requirement, requiring SRTP will provide
> security only in a very narrow sense of the word. At the same time I do
> believe that extra standard requirements will stifle innovation and  will
> complicate new service or application creation.
>
> I have no objection to making DTLS-SRTP a required to implement protocol.
> _____________
> Roman Shpount
>
>
> On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund <
> magnus.westerlund@ericsson.com> wrote:
>
>> WG,
>>
>> In todays RTCWEB WG meeting there was discussion around media security
>> mechanism. In this meeting there was some clear consensus in the
>> meeting which we would like to confirm on the list.
>>
>> The first was that there was overwhelming consensus that all RTP
>> packets SHALL be protected by SRTP.
>>
>> Secondly that no one objected against making DTLS-SRTP a mandatory to
>> implement and the default keying mechanism. Additional mechanisms are
>> not precluded.
>>
>> WG participants may state their position regarding these consensus calls
>> until 12th of April when the chairs will declare the final consensus. If
>> you where present in the meeting room and comment on this, please
>> indicate that.
>>
>> Best Regards
>>
>> Magnus Westerlund
>> For the WG chairs
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>