Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)

Igor Faynberg <> Thu, 05 April 2012 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 842CC21F875D for <>; Thu, 5 Apr 2012 10:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.227
X-Spam-Status: No, score=-8.227 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c9AFA2haP9AN for <>; Thu, 5 Apr 2012 10:55:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E9BB821F8753 for <>; Thu, 5 Apr 2012 10:55:11 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id q35HtASK012310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <>; Thu, 5 Apr 2012 12:55:11 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id q35HtAkT031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Thu, 5 Apr 2012 12:55:10 -0500
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id q35HtAhR003963; Thu, 5 Apr 2012 12:55:10 -0500 (CDT)
Message-ID: <>
Date: Thu, 05 Apr 2012 13:55:09 -0400
From: Igor Faynberg <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
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, 05 Apr 2012 17:55:12 -0000

On 4/5/2012 1:07 PM, Fabio Pietrosanti (naif) wrote:
> ...
> Well, the main point is that DTLS-SRTP claim to provide end-to-end
> encryption, however the user is not able to deliver "end-to-end security" .
> end-to-end encryption != end-to-end security .

Yes, so far this is how I read the present state of affairs.  We had a 
very interesting meeting with BrowserID people, but it was too short--at 
least for me--to figure everything out.

I find the issue of self-signed certificates problematic, too.

DTLS-SRTP would provide end-to-end security though if 1) the end points 
had a common PKI chain of trust or 2) if each of them could be 
authenticated to another by an assertion from a trusted IdP.  In neither 
case there would be a key escrow, right?

A level below is the KDC (Kerberos-like) arrangement.  Here both end 
points would need to trust the KDC, and  there are serious business 
cases for that.

> ...
> This bring a misleading concept on DTLS-SRTP in WebRTC because it's
> referred as end-to-end encryption, but it doesn't provide end-to-end
> security like other encryption technologies does (ZRTP, OpenPGP, OTR, etc).
> DTLS-SRTP rely on third party for security verification.
> DTLS-SRTP = end-to-site security
> SRTP-SDES = end-to-site security
> ZRTP = end-to-end security
> This means that DTLS-SRTP, from a trust-model point of view, does not
> provide end-to-end security because there will always be a trusted third
> party able to authorize Man in the Middle to do eavesdropping.
> > From that point of view SDES-SRTP provide very similar warranty, except
> that you have to trust only 1 third party rather than 2 third party.

Yes, now I understand what you were saying. I agree.  SRTP-SDES is, in 
fact, what should work with KDC.

And, to throw oil to the fire, did take a look at IBAKE RFCs?  This 
provides an interesting example of what you call end-to-site.