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 15:49 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 13CE821F8712 for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 08:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.854
X-Spam-Level:
X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 momEYPMYd3e0 for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 08:49:23 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB921F85C3 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 08:49:18 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q35FnHjv029405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Thu, 5 Apr 2012 10:49:18 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q35FnHUC009347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Thu, 5 Apr 2012 10:49:17 -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 q35FnH0K028351; Thu, 5 Apr 2012 10:49:17 -0500 (CDT)
Message-ID: <4F7DBEFC.6040302@alcatel-lucent.com>
Date: Thu, 05 Apr 2012 11:49:16 -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>
In-Reply-To: <4F7D7103.6040102@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.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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 15:49:24 -0000

Fabio,

I am finding these definitions hard to understand.  I am afraid that 
somehow the activity (encryption) gets mixed with the services 
(confidentiality and authentication).

  I think your major point is that effective encryption must rely on 
symmetric keys, and that the key distribution is crucial to ensuring 
confidentiality provably.  I agree with that.

I also agree with sepating the case when session keys are handed out by 
another entity (such as KDC) and the case where the keys are known only 
to the end-points.  The latter can be achieved with signed 
Diffie-Hellman (using PKI, or PAK, or EKE).

Confidentiality, of course, relies on authentication: If I encrypt 
something with the key I share only with you, I'd better know that I 
share this key ONLY with you.

But I don't get the point of the taxonomy you propose...

Igor

On 4/5/2012 6:16 AM, Fabio Pietrosanti (naif) wrote:
> Hi,
>
> i've been discussing with several friends about the current discussion
> on the security standard in this mailing lists, in particular regarding
> the topic of DTLS-SRTP trust model posted there
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04007.html .
>
> I found that there is no common definition for the concept of
> "end-to-end encryption" and there are a lot of misunderstanding about it.
>
> In particular, the fact that two peer can community by exchanging keys
> directly among them, tend to typically to be defined as end-to-end
> encryption.
>
> However the term "end-to-end encryption" have also a general
> misconception that's something that "no one can intercept" .
>
> Unfortunately this is not true for DTLS-SRTP, while for example it's
> true for OpenPGP/MIME or for ZRTP with SAS.
>
> We need to separate the 4 concepts:
>
> - end-to-end encryption
> Ability for a key management system to exchange keys directly without
> relying on intermediate server actively involved in encryption process.
>
> - end-to-end authentication
> Ability for end-user to authenticate the end-to-end encryption process
> without the need to rely on a single or multiple set of trusted third
> parties
>
> - end-to-site encryption
> Ability for a key management system to exchange keys with/trough the
> server with which data are exchanged, involving it in the authentication
> process.
>
> - end-to-site authentication
> Ability for end-user to authenticate the end-to-site encryption process
> based on the same security mechanism used to establish trust with the
> server with which data are exchanged.
>
>
> What i would like to focus is that:
>
> - DTLS does provide end-to-end encryption (in specific context of use)
> - DTLS does provide end-to-site authentication (rely on third party trust)
>
> - ZRTP does provide end-to-end encryption (in all context of use)
> - ZRTP does provide end-to-end authentication (does not rely on third
> party trust)
>
> - SDES-SRTP does provide end-to-site encryption (encryption with/trough
> your server)
> - SDES-SRTP does provide end-to-site authentication (you trust your
> server involved in key exchange)
>
> So when we tend to think about the "how much security a technology
> provide" we should probably compare in a scale:
>
> - ZRTP
>    - end-to-end encryption
>    - end-to-end authentication
> - DTLS-SRTP
>    - end-to-end encryption
>    - end-to-site authentication
> - SDES-SRTP
>    - end-to-site encryption
>    - end-to-site authentication
>
> So currently we can affirm that:
>
> - ZRTP does not rely on third party trust for effective security
> - DTLS-SRTP rely on third party trust for effective security
> - SDES-SRTP rely on third party trust for effective security
>
> This is the *MOST IMPORTANT* distinction for an encryption technology:
> 			WHO SHOULD I TRUST?
>
> Well, basically it seems to me that DTLS-SRTP and SDES-SRTP both require
>
> So, my point are to:
>
> - Introduce SDES-SRTP for compatibility and simplicity
>    - Specify that the Browser will need to provide indicate the security
> level to the user (like the lock of HTTPS, same security model)
>
> - Introduce end-to-end authentication support for DTLS-SRTP via SAS
>    - Specify that the browser will need to to provide the end-user way to
> use end-to-end authentication and indicate the security level to the user.
>
> Then it will be up to the signaling server and/or to the browser
> settings to specificy the required security model:
> - end-to-end encryption + end-to-end authentication
> or
> - end-to-site encryption + end-to-site authentication
>
> But please don't mix those two as it will be *Very difficult, near to
> impossible* to explain to the user "WHO SHOULD HE TRUST" .
>
> Fabio
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb