Subject: [rtcweb] Security Architecture: SDES support is a MUST

From: "Domenico Colella" <[email-masked]>
Date: Thu, 19 Jul 2012 09:42:47 +0200

In RTCWEB Security Architecture (draft-ietf-rtcweb-security-arch-03) I noticed an open issue regarding SDES support: if browser implementations MUST or MAY support it. 
I got quite scared when I saw the word MAY.
I support the MUST option, because RTCWEB can be used not only for peer-to-peer communication (i.e. Alice calling Bob), but also to access services provided by the "calling service"  (i.e.customer support, customer attendant, voicemail ... or any service delivering also RT audio/video that can be accessed through a website). In the latter case, the user usually is already logged-in the "calling service" using a secure connection (X.509 certificate have already be used to verify calling service party) and the other endpoint usually is a server/phone in company DMZ/intranet: communication is end-to-end secured and each party trusts the other. At the moment SDES has a good support and it is not that difficult to be implemented, on the contrary DTLS-SRTP it is almost unknown.
Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and compatible with their legacy devices ?) or translators in order to support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free products as Red5) and use FLASH ? At the moment FLASH is supported  by a considerably larger number of devices, and uses codecs "more compliant" to legacy devices (iLBC is not that supported by phone equipments).
Furthermore, in this scenario, the customer using i.e. the bank website knows for sure he is communicating "privately" to his bank and trusts the webserver. Why then setup a DTLS session or  check identities ? If  the customer is sending passwords, credit card numbers,... using webserver connection why do not "trust" such connection to exchange RTP keys as well ?
The word MUST is really important, because it grants that "every" browser in the near future will support it and grants system integrators, software developers and companies investing in building RT services that SDES support will be mantained.
Regards,
Domenico Colella

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 19 Jul 2012 12:25:34 -0400

On 7/19/2012 3:42 AM, Domenico Colella wrote:
> ...
> Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and compatible with their legacy devices ?) or translators in order to support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free products as Red5) and use FLASH ?..

Why is a "DTLS-SRTP gateway" needed--expensive or cheap?   DTLS-SRTP is 
end-to-end.

Igor

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 19 Jul 2012 18:29:21 +0200

On 7/19/12 6:25 PM, Igor Faynberg wrote:
>> Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and
>> compatible with their legacy devices ?) or translators in order to
>> support RTCWeb instead of a SRTMP server/gateway (i.e. open-source
>> free products as Red5) and use FLASH ?..
> 

DTLS-SRTP does not provide end-to-end security in the WebRTC model, as
already discussed in this mailing list.

DTLS-SRTP does provide end-to-end encryption WITHOUT end-to-end security.

Fabio

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 19 Jul 2012 13:42:47 -0400

If both parties have certificates, DTLS will provide end-to-end 
security.  (I have not yet heard a convincing argument why  the 
certificates--I mean not self-signed ones--cannot be used.)  And if the 
parties share a key, DTLS will work, too.

Igor

On 7/19/2012 12:29 PM, Fabio Pietrosanti (naif) wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2012 11:03:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Domenico Colella
> Sent: Thursday, July 19, 2012 12:43 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [rtcweb] Security Architecture: SDES support is a MUST
> 
> In RTCWEB Security Architecture (draft-ietf-rtcweb-security-arch-03) I
> noticed an open issue regarding SDES support: if browser
> implementations MUST or MAY support it.
> I support the MUST option, because RTCWEB can be used not only for
> peer-to-peer communication (i.e. Alice calling Bob), but also to access
> services provided by the "calling service"  (i.e.customer support,
> customer attendant, voicemail ... or any service delivering also RT
> audio/video that can be accessed through a website). In the latter
> case, the user usually is already logged-in the "calling service" using
> a secure connection (X.509 certificate have already be used to verify
> calling service party) and the other endpoint usually is a server/phone
> in company DMZ/intranet: communication is end-to-end secured and each
> party trusts the other. At the moment SDES has a good support and it is
> not that difficult to be implemented, on the contrary DTLS-SRTP it is
> almost unknown.

Doing SDES in RTCWEB means that SDES will persist in RTCWEB forever.

SDESC combined with DTLS-SRTP complicates call transfers, three party 
calls (such as when a credit card issuer might conference a merchant 
and the cardholder into the same call), and SDES cannot provide 3rd 
party identity like can be done with DTLS-SRTP's handshake.

There are more reasons; those are off the top of my head.

> support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free
> products as Red5) and use FLASH ? At the moment FLASH is supported  by
> a considerably larger number of devices, and uses codecs "more
> compliant" to legacy devices (iLBC is not that supported by phone
> equipments).

As I explained at IETF83 in Paris at the RTCWEB, interworking
between DTLS-SRTP keying and SDESC keying can be done without 
expensive CPU operations.  Reference
http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt

And, as I explained at IETF83 in Paris, some sort of gateway to 'legacy'
equipment is going to be necessary for other reasons.  Codec
incompatibility (as you note) and responding to 'consent' 
checks (to reduce the impact of RTCWEB as an attack vector) will both
be necessary on the media path for a lot of 'legacy' equipment.

> Furthermore, in this scenario, the customer using i.e. the bank website
> knows for sure he is communicating "privately" to his bank and trusts
> the webserver. Why then setup a DTLS session or  check identities ?

Call transfers and three way calls are when SDES and real identity
are important.  I want RTCWEB to evolve beyond simple, point-to-point
calls.

> If
> the customer is sending passwords, credit card numbers,... using
> webserver connection why do not "trust" such connection to exchange RTP
> keys as well ?
> The word MUST is really important, because it grants that "every"
> browser in the near future will support it and grants system
> integrators, software developers and companies investing in building RT
> services that SDES support will be mantained.

The corollary is also true: allowing SDESC in WEBRTC means that SDESC 
will persist in _every element_ of WEBRTC, forever.  This means
every element of WEBRTC will incur the costs of interworking with
DTLS-SRTP, call transfers, and 3 way calls.

I would rather that effort be constrained to the edge of those 
'legacy' networks that are using SDESC.  As those atrophy or as those 
'legacy' network endpoints add DTLS-SRTP support, Consent support,
and codec support, the gateway functions will be reduced and 
eventually eliminated.

-d

---

From: Roman Shpount <[email-masked]>
Date: Thu, 19 Jul 2012 16:19:04 -0400

> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt
Even though I understand how you can bridge DTLS-SRTP with SRTP-EKV without
re-encryption, I do not think it is possible to bridge SDES-SRTP with
DTLS-SRTP the same way. Bridging DTLS-SRTP with SRTP-EKV is completely
useless for legacy interop since old equipment is more likely to support
DTLS-SRTP then EKV, which is not even standardized yet.

This being said, I am strongly against supporting SDES-SRTP. Re-encoding is
cheap and you can do nearly 10GB/s of AES encoding on a fairly modest
modern server. Having more protocols to test and support is a much higher
cost.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Jul 2012 13:40:54 -0700

Self-signed certificates are only appropriate for a subset of scenarios.  Do
we expect IdP to be widely deployed in high security scenarios for
government, financial or medical applications?  I do not.
  
Do we expect a call center to utilize IdP with a self-signed certificate?
More likely is that they will utilize a certificate chaining to a trust
anchor. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Igor Faynberg
Sent: Thursday, July 19, 2012 10:43 AM
To: [email-masked]
Subject: Re: [rtcweb] Security Architecture: SDES support is a MUST

If both parties have certificates, DTLS will provide end-to-end security.
(I have not yet heard a convincing argument why  the certificates--I mean
not self-signed ones--cannot be used.)  And if the parties share a key, DTLS
will work, too.

Igor

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 19 Jul 2012 15:20:52 -0700

> From: Roman Shpount [mailto:[email-masked]]
> Sent: Thursday, July 19, 2012 1:19 PM
> To: Dan Wing
> Cc: Domenico Colella; [email-masked]; [email-masked]
> Even though I understand how you can bridge DTLS-SRTP with SRTP-EKV
> without re-encryption, I do not think it is possible to bridge SDES-
> SRTP with DTLS-SRTP the same way.

Short answer:  you are right, the WEBRTC network needs DTLS-SRTP 
and EKT.

Without EKT, it is possible to interwork in one direction without re-keying 
each SRTP packet, specifically the packets going from the DTLS-SRTP
network to the SDESC network can be forwarded without re-keying.  However,
in the the other direction (from SDESC network to DTLS-SRTP network), those
SRTP packets would need to be rekeyed.  This is depicted in slide
28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf
where the media gateway is on fire (it is doing lots of CPU processing
to rekey those SRTP packets in the 'red' direction).

To avoid that rekeying in that direction, we add EKT on the DTLS-SRTP
network.  With EKT, there is no longer a need to rekey SRTP in either
direction.  This is depicted in slide 33 of the same presentation as
above.

EKT has other advantages for group video conferencing, which allow
video switching devices to avoid re-keying -- which reduces costs
(and saves energy, everybody is about saving energy!).  It was those
advantages which led to the design of EKT in 2006 as 
draft-mcgrew-srtp-ekt-00, and the implementation in Cisco's 
telepresence systems.

> Bridging DTLS-SRTP with SRTP-EKV is
> completely useless for legacy interop since old equipment is more
> likely to support DTLS-SRTP then EKV, which is not even standardized
> yet.

The majority of legacy systems seem to use SDESC keying, not 
DTLS-SRTP keying.  And we don't need to change those legacy systems 
for this interworking.

There were no DTLS-SRTP implementations brought to SIPit 29,
https://www.sipit.net/SIPit29_summary, and 80% that had SRTP support
used SDESC keying.  Assuming that SIPit is a more-or-less accurate 
representation of the market, the 'legacy' market uses SDESC keying
if it supports SRTP at all.

Of course, there is also a lot of 'legacy' equipment only supports
RTP.  That is yet another reason for an interworking gateway in 
front of that RTP-only equipment.

> This being said, I am strongly against supporting SDES-SRTP. Re-
> encoding is cheap and you can do nearly 10GB/s of AES encoding on a
> fairly modest modern server. Having more protocols to test and support
> is a much higher cost.

Some objected to that cost, and after Magnus and Jonathan Lennox
suggested EKT be changed slightly to allow each packet to be self-
describing, we now have a very efficient way to interwork the
SRTP packets.

-d

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Fri, 20 Jul 2012 08:16:25 +0200

> More likely is that they will utilize a certificate chaining to a trust

Until WebRTC does not employ an end-to-end authentication mechanism
(like ZRTP's SAS applied to DTLS-SRTP), WebRTC is not going to provide
end-to-end security.

It's not a matter of considering just the encryption, but considering
the "trust model" .

Current security definition of WebRTC does not support end-to-end security.

Fabio

p.s. we have wrote tons of thread about it in past months explaining why
and how

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Jul 2012 15:06:53 +0200

> Current security definition of WebRTC does not support end-to-end security.
The current security definition of WebRTC (with DTLS) provides fingerprints.
If the application is able to verify those fingerprints, security is end 
to end; if it isn't - it isn't.

One specification does not solve all problems.

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Fri, 20 Jul 2012 15:18:36 +0200

> to end; if it isn't - it isn't.

The security specification already does specify how the fingerprint must
be checked, against a third party system that must be trusted (unless
there is some recent update i didn't still checked).

The way the specification describe fingerprint must be checked, does not
enforce end-to-end security but always rely on trusted third party,
being IdP (identity providers).

The only way to achieve end-to-end security is not to have any kind of
trusted third party, as has been already discussed on
http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html .

Until WebRTC security architecture specification does not clearly define
a peer-to-peer fingerprint verification system that does not rely on
trusted third party it cannot be considered to provide end-to-end security.

Fabio

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Jul 2012 15:28:07 +0200

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg04043.html .
That link is your request to have SAS considered mandatory.

I believe you got some support for that proposal, or at least some kind 
of availability of digest information that can be verified 
independently, but I do not believe that you got any support for having 
SAS be the one and only definition of "end to end security".

Thus, you may get support for your real request, but not for the 
language you use to describe it.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2012 06:50:28 -0700

The draft currently states:

     *  The "security characteristics" MUST include some mechanism to
         allow an out-of-band verification of the peer, such as a
         certificate fingerprint or an SAS.

I'd be happy to have us specify a particular fingerprint algorithm (presumably
SHA-256, potentially truncated) but I haven't seen any evidence that
users savvy enough to inspect the fingerprint at all can't navigate more
than one hash. For example, Chrome's SSL/TLS inspector currently displays
MD5 and SHA-1. So I'm not sure something needs to be standardized here.

-Ekr

On Fri, Jul 20, 2012 at 6:28 AM, Harald Alvestrand <[email-masked]> wrote:
> I believe you got some support for that proposal, or at least some kind of
> availability of digest information that can be verified independently, but I
> do not believe that you got any support for having SAS be the one and only
> definition of "end to end security".
>
> Thus, you may get support for your real request, but not for the language
> you use to describe it.
>
>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Jul 2012 10:30:03 -0700

> Behalf Of Eric Rescorla
> Sent: Friday, July 20, 2012 6:50 AM
> To: Harald Alvestrand
> Cc: [email-masked]

Users are unreliable to do this.  

I would look at TLS key pinning or similar techniques.  That is what 
ZRTP is doing to avoid speaking a SAS for every phone call.

Again (for the group), DTLS-SRTP allows us to build identity validation
such as key pinning or a SAS or third-party IdP, but SDESC does not 
allow us to build identity validation.

-d

---

From: Alan Johnston <[email-masked]>
Date: Fri, 20 Jul 2012 13:20:42 -0500

If we want to have usable end-to-end or human-to-human authentication,
then just displaying a 128 bit fingerprint isn't going to work.

ZRTP ( RFC 6189) uses a hash commitment to reduce this to an 8 bit
fingerprint, and has human friendly ways to exchange this, such as
base 256:

     http://en.wikipedia.org/wiki/PGP_word_list

There have been claims over the years that DTLS-SRTP could do this as
well, but I have never seen a specification or a description of how
would be done.

- Alan -