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

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Thu, 05 April 2012 17:55 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 842CC21F875D for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 10:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.227
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9AFA2haP9AN for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 10:55:12 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E9BB821F8753 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 10:55:11 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q35HtASK012310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Thu, 5 Apr 2012 12:55:11 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35HtAkT031886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Thu, 5 Apr 2012 12:55:10 -0500
Received: from [135.244.43.110] (faynberg.lra.lucent.com [135.244.43.110]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q35HtAhR003963; Thu, 5 Apr 2012 12:55:10 -0500 (CDT)
Message-ID: <4F7DDC7D.7040001@alcatel-lucent.com>
Date: Thu, 05 Apr 2012 13:55:09 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4F7D7103.6040102@infosecurity.ch> <4F7DBEFC.6040302@alcatel-lucent.com> <4F7DD13F.2010006@infosecurity.ch>
In-Reply-To: <4F7DD13F.2010006@infosecurity.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: 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.

Igor