[rtcweb] On DTLS-SRTP trust model (and consideration for SDES-SRTP)

"Fabio Pietrosanti (naif)" <lists@infosecurity.ch> Tue, 03 April 2012 18:00 UTC

Return-Path: <lists@infosecurity.ch>
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 0E09311E809F for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 11:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.691
X-Spam-Level:
X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1]
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 OUhElBeL-+lC for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 11:00:43 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D628811E809D for <rtcweb@ietf.org>; Tue, 3 Apr 2012 11:00:42 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2720375wgb.13 for <rtcweb@ietf.org>; Tue, 03 Apr 2012 11:00:42 -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=uyqZTPRuu4VgmPh1rT0CsBhcsd7IQrj+EN3HhrFeOWw=; b=J/dhwGegE7Xwh9BqGwbinTK8baosZ6zIgeUMHvUsicR7LYTW8TrpMKe8ofP8CylRgx K2CM0g9BMkoogzAsU+qcXVcXrRq7qGsMs2w+qA+WsHES5X+VHn4Z1uBSjW9ibopBIM1C pYpK8lPIJNVhTXoIXkiky5oPmBNxcTHMwMbPsYg2VVvsHQwppeVFcRL32DbHt6LtUDKK FGV42LYN8LSfu9VCgr2V7jX8+vFzz1NKX+U/Grn4uGUCR8enbLPJ9RcHaw1jP7cwk9qz AHwXipMI5QNimeLn3gb/rdkyuG/vL2Bk7i4/vXGJCFMccHu8EptO47KfHHdPZpc1iDGy RnJw==
Received: by 10.180.84.164 with SMTP id a4mr38615303wiz.2.1333476042046; Tue, 03 Apr 2012 11:00:42 -0700 (PDT)
Received: from sonyvaiop13.local (host146-199-static.115-2-b.business.telecomitalia.it. [2.115.199.146]) by mx.google.com with ESMTPS id n20sm72198124wiw.5.2012.04.03.11.00.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 11:00:38 -0700 (PDT)
Sender: Fabio Pietrosanti <naif@infosecurity.ch>
Message-ID: <4F7B3AC1.8080804@infosecurity.ch>
Date: Tue, 03 Apr 2012 20:00:33 +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: ALoCoQmF27GcI6lcOPYvvIo8YGMAMLFq8XsqHRtIzA1UsUkp65zLvNzHoXOOZje48TUeN8ZzxNVP
Subject: [rtcweb] On DTLS-SRTP trust model (and consideration for 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: Tue, 03 Apr 2012 18:00:44 -0000

>From trust model SDES-SRTP it's very similar with DTLS-SRTP with the
regards to the need to trust third party with no real end-to-end
authentication/encryption support.

Let me explain this assumption:

- DTLS-SRTP key exchange without fingerprint/identity verification mean
"false sense of security" = no security

- DTLS-SRTP to verify fingerprint require identity services
- Identity services rely on trusted third parties
- Trusted third party identity services rely on TLS (https)

So basically in any case the 'root of trust' is based on TLS.

>From http://www.ietf.org/id/draft-ietf-rtcweb-security-arch-01.txt :

4.1.  Initial Signaling
[...]

   Based purely on the interface provided
   by the signaling server, they know that the signaling server claims
   that the call is from Alice to Bob.

4.3.  DTLS Handshake
[...]

   If Alice and Bob authenticated via their IdPs,
   then they also know that the signaling service is not attacking them.
   Even if they do not use an IdP, as long as they have minimal trust in
   the signaling service not to perform a man-in-the-middle attack, they
   know that their communications are secure against the signaling
   service as well.

5.1.  Origin and Web Security Issues

   The basic unit of permissions for RTCWEB is the origin [RFC6454].
   Because the security of the origin depends on being able to
   authenticate content from that origin, the origin can only be
   securely established if data is transferred over HTTPS [RFC2818].


So, while i totally agree to get DTLS-SRTP into the standard but please
don't consider it the "panacea" as it's trust model, for how it's proposed:
- DTLS-SRTP work securely when relying on trusted third party for idP
- DTLS-SRTP work securely when you trust the signaling services
- DTLS-SRTP work securely only when you trust third party that are trued
via other TLS/CA based trust chain:
  - signaling service (web server)
  - identity provider

So to have a "secure DTLS-SRTP" infrastructure that guarantee end-to-end
encryption the user is not independent (like for ZRTP SAS that the
authors of rtcweb-security-arch doesn't consider a valuable point) but
must rely on at least 2 separate third party services that rely on TLS
trust model.

With SDES-SRTP you get "less security" than what DTLS-SRTP can provide
but with an "order of magnitude" of simplicity because:
- SDES-SRTP work securely when relying on a single party for TLS

So again summarizing:

- DTLS-SRTP "can" provide end-to-end crypto...
...ONLY IF the user trust 2 services that rely on TLS
 (the user trust at least 2 different services, signaling + idP)

- SDES-SRTP "can" provide end-to-site crypto...
..ONLY IF the user trust 1 single service with TLS

That's my point in arguing that SDES-SRTP MUST be implemented for it's
strongest simplicity in implementation and in providing end-to-site
encryption without all the high complexity DTLS-SRTP.

But always consider that DTLS-SRTP, in order to be secure, still require
the user to trust some third party and it's not able to independently
verify the trust-condition of the other user.

It's a matter of considering which trust scenario you want to protect
about.

DTLS-SRTP represent the "elephant in a room" concept, where a *huge
level of complexity* is under the hood to be able to provide even a
basic security level (even end-to-site encryption), and the end-user
doesn't have a real way to understand "which security level" he is.

At least with SDES-SRTP the user know that there is less, but simpler to
be guaranteed, specific end-to-site security model (i connect to gmail,
i trust gmail snooping my email).

Please consider that as the stratification of complexity for DTLS-SRTP
will probably result in practical less-reduced-security.

IMHO any technology must provide protection against a specific risk
model, here in this WG we are saying that DTLS-SRTP is the panacea for
all the risk-model.

That's unfortunately not true.

There is "the right technology" to face "the right risk context" and
when you try to make the use of a "specific technology" to satisfy all
the risk context, the results are not always very good, due to the
complexity of different factors to be considered.

If we think that just providing something that can deliver "unsecure
end-to-end encryption" by providing a "false sense of security" is a
good things, let's goes on.

But imho every technology must be specifically adapted to a specific
risk scenario.

If we want to really consider DTLS-SRTP's end-to-end encryption, the
fingerprint checking must be completely in the hand of the user, with
ZRTP's like SAS checking and not rely on third party services for trust.

Fabio