Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC)

[Roman Shpount <[e-mail]>]

On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson <[e-mail]> wrote:

> If you support DTMF in RTP you already have a requirement that you SHOULD
>  only do that over SRTP. If rtcweb supports telephony-events, we are
> already on the SRTP side as almost mandatory. I think it's easier to reach
> an agreement on SRTP being mandatory than DTMF being dis-allowed.
>
>
Well, this is a perfect example when specifying mandatory security for
wrong reasons is simply being ignored. All the reactions I've seen to this
so far were "this is only a SHOULD, let's disregard this for now". Getting
security requirements in the standard which are too high too be practical
usually produces products which disregard security completely, reaching the
exactly opposite effect. I think, in this particular case, the right course
of action is to use AVT tones in RTP as the rest of the industry is doing
now.

Also, I wanted expand on the debug requirements: I do hope we will make key
exchange mechanism, different from SDES, mandatory for WebRTC. Passing
actual encryption keys through JavaScript makes media encryption to easy to
circumvent. This means some type of public/private key encryption used for
key exchange. If we do this right, getting to the actual key used for media
session encryption will be very difficult, so most of the tools currently
used for SRTP debugging will stop working. We will also end up with
something new, which will mean extensive need for debugging. Ability to
turn this component on and off will be very helpful for implementation
debugging. Once again, this will probably be not a critical point, but
making something easier for developers usually goes a long way in driving
the adoption.

One more benefit of having RTP as fallback for legacy interop is that it
will allow us to specify something that will be more secure for WebRTC. If
SDES support would no longer be needed, we can concentrate on using key
exchange mechanism that is actually secure.

Finally, (going slightly off topic here) it would probably be a good idea
to make key exchange part of the initial ICE transaction. This way we can
use this key exchange as an additional verification of the remote party,
and reduce the number of round trips required before the media flow is
established.
_____________
Roman Shpount