Re: [rtcweb] Consensus call regarding media security

"Fabio Pietrosanti (naif)" <> Thu, 29 March 2012 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4394021E8125 for <>; Thu, 29 Mar 2012 10:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.197
X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1vhRjwVcnByz for <>; Thu, 29 Mar 2012 10:56:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6696C21E8117 for <>; Thu, 29 Mar 2012 10:56:51 -0700 (PDT)
Received: by wibhq7 with SMTP id hq7so259023wib.13 for <>; Thu, 29 Mar 2012 10:56:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:x-gm-message-state :content-type:content-transfer-encoding; bh=u5SGLP1fRrxkQGjxiqngfDWZmGkAQ53PJRIojIVTQn0=; b=SagXzZa/1mkvGqyYcydmHsFkoF/+ckbCzcBmRfYIyisTDnIXryRi8Vj2otQVcVYsw5 lEdLRGoljzW6wJ3RGCXURGIivqzHCtttiZ1MwvAimLVawBvcXHdgE6m91AU5OltXie6Z I5Twzw5ncY93B+fUtvXSJsypsS/4qaxLt/XhMighGeekD8plo8ks/ndUJ/l9iAS7CMjB OPBEs7PhuvGygHCUaxQ+nofJ+nKrVPPS4Hw9/AZdeTTcFFdQg/BcDvqBnj9lQBN0H9F1 1zETQlWqxD4wWl8RXkBGotCUrKZPV65MSrw9wuoAH/cJiDfWgivCaBu7TDjJCSFsPbcC TbtQ==
Received: by with SMTP id gk5mr9290713wib.3.1333043810391; Thu, 29 Mar 2012 10:56:50 -0700 (PDT)
Received: from sonyvaiop13.local ( []) by with ESMTPS id b3sm68760917wib.4.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 10:56:49 -0700 (PDT)
Sender: Fabio Pietrosanti <>
Message-ID: <>
Date: Thu, 29 Mar 2012 19:56:47 +0200
From: "Fabio Pietrosanti (naif)" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
References: <> <BLU169-W80FA8377288974CAF4716F93480@phx.gbl> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4
X-Gm-Message-State: ALoCoQkn2bFnt/MOr6/d2r7ac+NRnlx1T7AGI68B6yzheQ3znraVgTPHfhP0Lnik8nPNf8DE6Hka
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Consensus call regarding media security
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2012 17:56:52 -0000

On 3/29/12 2:35 PM, Magnus Westerlund wrote:
> On 2012-03-29 08:02, Bernard Aboba wrote:
>> I agree with proposition #1 (SRTP) unconditionally.
>> With respect to proposition #2 (DTLS-SRTP), perhaps the words "with
>> details to be worked out" should have been added. 
>> I believe that the consensus achieved was only on a general direction,
>> not an endorsement of particular proposals.
>> Personally, I would like to have more specifics about the required
>> features of DTLS-SRTP in the RTCWEB context.
> I hope someone that knows the details can elaborate on this. I thought
> DTLS-SRTP has a core that you will need to implement. Then there is
> clearly a question of crypto algorithms to be supported. But that also
> applies to SRTP where we also need to select which crypto suites that
> are to be implemented if any in addtion to the MITM. The WG will need to
> select these details as part of the next steps.

Hi Magnus,

imho the selection of a crypto algorithms is not the first priority (it
will probably goes with some well known AES-stuff), as the first
priority is to define which will be the Key Management system to be used

Given the SRTP standard,the security and trust model radically change
depending on the key exchange system details.

With DTLS-SRTP the key exchange and security/trust model seems quite
opaque and there's not a specific guideline to implement it and/or to
satisfy a specific security requirement.

While the SDES-SRTP method satisfy  all the 4.1.1.* Calling method
requirement of ,
because it would just rely on existing TLS/HTTPS method.

So it would not even enter into the context/discussion of trust with the
server, that has been already managed by the existing TLS/HTTPS.

I did not really understand how DTLS-SRTP would like to manage the
so-many-complicated trust scenario that TLS/HTTPS already manage.

Imho everything should be simplified with two context:
- Do you need end-to-site (TLS equivalent) security?

- Do you need end-to-end (ZRTP/PGP equivalent) security?
  DTLS-SRTP with user-driven verification schema (such as Short
Authentication String / Fingerprint / Key pinning)

Fabio Pietrosanti
Founder, CTO

Tel: +39 02 85961748 (direct)
Mobile: +39 340 1801049
Skype: fpietrosanti

PrivateWave Italia S.p.A.
Via Gaetano Giardino 1 - 20123 Milano - Italy