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

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 05 Apr 2012 12:16:35 +0200

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

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 05 Apr 2012 11:49:16 -0400

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:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 05 Apr 2012 19:07:11 +0200

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

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 .

In the encryption technologies landscape, when we refer to end-to-end
encryption we always refer to cryptographic architecture where the users
communicating are guaranteed respect to the underlying transport and
communication architecture.

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.

Fabio

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 13:42:17 -0400

> party able to authorize Man in the Middle to do eavesdropping.

Incorrect. If fingerprint is exposed and can be verified, DTLS-SRTP does
provide end-to-end security. No third parties involved.
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 19:43:52 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> On Thu, Apr 5, 2012 at 1:07 PM, Fabio Pietrosanti (naif)
> <[email-masked]> wrote:
>>

The fingerprint is included in the SDP which goes throught the Web
server, right? You know what I mean ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 05 Apr 2012 13:55:09 -0400

On 4/5/2012 1:07 PM, Fabio Pietrosanti (naif) wrote:
> ...

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.

> ...

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

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 05 Apr 2012 20:10:36 +0200

On 4/5/12 7:42 PM, Roman Shpount wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

No, you are wrong in the understanding.

The fingerprint is always delivered from the signaling services, so by
the HTTPS website providing the JS calling application.

>From :
                      RTCWEB Security Architecture
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-01#section-4.1

4.1.  Initial Signaling
[...]

In either case, it will contain:

   o  Media channel information
   o  ICE candidates
   o  A fingerprint attribute binding the communication to Alice's
      public key [RFC5763]

[...]
   This message is sent to the signaling server, e.g., by XMLHttpRequest
   [XmlHttpRequest] or by WebSockets [RFC6455] The signaling server
   processes the message from Alice's browser

So basically the "signaling service" provide the fingerprint information.

Additionally, in case you want to trust the fingerprint verification via
an identity provider, please read below:
From:
		RTCWEB Generic Identity Provider Interface
http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00#section-5.4.1

5.4.3.1.  Authenticating Party
[...]
   o  If a IdP is provided by the calling application use that.

The IdP is provide *by the signaling service*.

So basically:

- The user get the calling application from signaling service
- The user get the fingerprint from signaling service
- The user get the IdP from the signaling service

So basically the signaling service can ALWAYS do MITM and provide
eavesdropping services to authorized and non-authorized users.

>From a trust model point of view:

		DTLS-SRTP = SDES-RTP

Because in both case the "signaling service" is a trusted third party
able to intercept phone calls.

It's important to define clearly somewhere that "WebRTC does not provide
end-to-end security"

Fabio

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 14:17:21 -0400

On Thu, Apr 5, 2012 at 2:10 PM, Fabio Pietrosanti (naif) <
[email-masked]> wrote:

> If fingerprint is exposed to the user and be compared through some
alternative communications channel, the it can provide an independent
security validation similar to the one used in ZRTP. If signaling server
replaces the fingerprint for some sort of attack this can be detected, even
though it can be argued that very few people will do so.
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 20:19:39 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> security validation similar to the one used in ZRTP.

Define such an "alternative communications channel" and explain me how
the signaling server cannot alter that channel.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 14:24:20 -0400

> the signaling server cannot alter that channel.
I will send it to you using Frogo, my trusty carrier pidgin ;).

I can read them to you (possible to modify but much harder then simple
signaling), I can email them to you using some sort of trusted service, or
I can call you using old fashioned telephone. I remember times when such
keys were exchanged via fax.
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 20:44:57 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> signaling), I can email them to you using some sort of trusted service, or I
> can call you using old fashioned telephone. I remember times when such keys
> were exchanged via fax.

So the success of DTLS (the "security end-to-end panacea") depends on
two users of any web sharing their "keys" via email, phone, or fax...

Did you forget the <sarcasm> tag? XD

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 6 Apr 2012 06:24:02 +0000

Fabio,

End-to-end looks misnomer to me as the maximum media security/authentication provided shall be between two media hops. The media hops in the RTCWeb are web-browser. So, the aim of the media security/authentication mechanism has to between two web-browsers. The intermediate elements like http proxy should not be in a position to perform MITM attack or atleast, web-browser should have the mechanism to perform post-mortem analysis that man-in-the-middle exist as HTTP proxy. I wish to see the discussion for media security/authentication between web-browser to web-browser first.

Please note that web-browser is not required to standard browser like Chrome, IE, Mozilla but web-browser shall be custom-made which is RTCWeb compliant.

AFAIK, SDES-SRTP does not provide web-browser to web-browser authentication and it shall mimic web-browser to web-browser security. I agree with Hadriel that SDES-SRTP mechanism provides marketing advance as most of the user atleast believes that the session is secured :-) but it should not be criteria for selecting key mechanism.  We shall discuss in detail about DTLS-SRTP or zRTP or any other mechanism if exists for web-browser to web-browser media security.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Fabio Pietrosanti (naif)
>Sent: Thursday, April 05, 2012 3:47 PM
>To: [email-masked]
>Subject: [rtcweb] End-to-end encryption vs end-to-end authentication
>(DTLS-SRTP / SDES-SRTP)
>
>Hi,
>
>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.
>
>- end-to-end encryption + end-to-end authentication or