[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

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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)
Precedence: list

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

Re: [rtcweb] End-to-end encryption vs end-to-end … Fabio Pietrosanti (naif)
[rtcweb] End-to-end encryption vs end-to-end auth… Fabio Pietrosanti (naif)
Re: [rtcweb] End-to-end encryption vs end-to-end … Igor Faynberg
Re: [rtcweb] End-to-end encryption vs end-to-end … Roman Shpount
Re: [rtcweb] End-to-end encryption vs end-to-end … Iñaki Baz Castillo
Re: [rtcweb] End-to-end encryption vs end-to-end … Igor Faynberg
Re: [rtcweb] End-to-end encryption vs end-to-end … Fabio Pietrosanti (naif)
Re: [rtcweb] End-to-end encryption vs end-to-end … Roman Shpount
Re: [rtcweb] End-to-end encryption vs end-to-end … Iñaki Baz Castillo
Re: [rtcweb] End-to-end encryption vs end-to-end … Roman Shpount
Re: [rtcweb] End-to-end encryption vs end-to-end … Iñaki Baz Castillo
Re: [rtcweb] End-to-end encryption vs end-to-end … Ravindran, Parthasarathi