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

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Domenico Colella
> Sent: Thursday, July 19, 2012 12:43 AM
> To: rtcweb@ietf.org
> Cc: daniele.filippi@ctiplanet.it
> 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 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.

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.

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

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

> Regards,
> Domenico Colella
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb