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

"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> Thu, 05 April 2012 10:16 UTC

Return-Path: <lists@infosecurity.ch>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id ECC3221F864C for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 03:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wtKJdmb48qqT for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 03:16:41 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id EBD7321F8611 for <rtcweb@ietf.org>; Thu, 5 Apr 2012 03:16:40 -0700 (PDT)
Received: by eeke51 with SMTP id e51so399425eek.31 for <rtcweb@ietf.org>; Thu, 05 Apr 2012 03:16:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=NNiUgtHXBF8Go5eFrir+5xtNfVJDy8SzC464IgHFBs0=; b=Ki42bYCwZHhObLZfWpCs10DjhXJQECvbmjWdkvScFAhvznRDPeLMOxVuq4vZO2/wF9 Ot2ti3gKAL3+NbK5ZMJcdonGG5N0msm4dcs/gckkFRdS1fCSZPoHhXvPqOUp5g5AVH3s a6l4a89eCvuyFtvv1VQNoQ8vPrHlK8QOmCNAQBpaVj0+VkgYGqWcttyG8kzTlTw2E3Qp 0Ue/DehucfmUUCWBMzlotAR7gGFJlj0MJdlLHc1bMbdmnWSR7AsqwQmzWLf0Sy3aW9lB Fcm96mlwD53ALBTEshQJeYy8h3xmWg8SCz6R9zKYGmzb4Yrz2jgdMCeVX50oc5hWNO63 omzQ==
Received: by with SMTP id q4mr344219ebq.294.1333620999466; Thu, 05 Apr 2012 03:16:39 -0700 (PDT)
Received: from sonyvaiop13.local (93-57-41-37.ip162.fastwebnet.it. []) by mx.google.com with ESMTPS id m42sm11573650eef.0.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 03:16:38 -0700 (PDT)
Sender: Fabio Pietrosanti <naif@infosecurity.ch>
Message-ID: <4F7D7103.6040102@infosecurity.ch>
Date: Thu, 05 Apr 2012 12:16:35 +0200
From: "Fabio Pietrosanti (naif)" <lists@infosecurity.ch>
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
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkWMLmRYTzn49mYRC7zjFv61ANNgwoDoKF5yTk6CdtRIj2y5zo00AKJGa8GHzZ2iWPrEbI1
Subject: [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
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 10:16:42 -0000


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

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

- 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

- 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:

  - end-to-end encryption
  - end-to-end authentication
  - end-to-end encryption
  - end-to-site authentication
  - 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:

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
- 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" .