Re: [rtcweb] Retransmit: Summary of Alternatives for media keying

[Randell Jesup <[e-mail]>]

On 7/29/2011 10:30 AM, Matthew Kaufman wrote:

> What I said to start this whole thing was: the two alternatives should not be described as choosing between secure and insecure.  BOTH alternatives require the user to verify something for the call to be secure.  BOTH alternatives have the potential to be very secure.  That is all.
> I suppose that depends on what you mean by "the potential to be very secure"... certainly plain RTP *might* be secure, if it never leaves your desktop.
>
> DTLS-SRTP + a security inspection UI gives the user a way to verify something *independently of the service provider* to see if the call is secure. SDES does not. The only way to be sure the service provider isn't colluding with someone to tap your call when you use SDES is to agree with the other party to mangle the key you receive from the service provider. (The "pessimist" approach to trust in this environment.)
This is where there's an opening for browser extensions, potentially (mangling
the agreed-to-by-protocol keys, such as by using a pre-shared secret) - though that
would require some level of external interaction with the keying from JS/etc code.
That may be worth exposing to the W3/JS layer, perhaps.  (Should the JS layer have access
to the keys?  Be able to modify them (per above)?  Security implications?  What if it
wants to implement an "answering-machine" function via recording packets for later
replay?  Or will it have  access to decoded packets,  or will it only have access
to decoded media and have to re-encode it for "answering-machine" use?)

If the user and the person they're talking to has the option of using an extension
(or the app) to modify the keys at both ends, that allows for perfect(*) security via
pre-shared secrets of whatever form.

* Nothing is perfect


>> BTW, I am assuming of course that even if we choose the alternative of DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer cannot do it then SDES, and if the peer can't do that then RTP. (assuming the human has set whatever browser knobs are necessary to enable/disable this stuff)
> Agree. Though the human needs to be able to see a lot more about what is going on if we allow all three.

Mostly that the user be allowed to see it, and that if one does put up 
any sort of Lock icon it would
only be for the "most" secure.  (Though this is a security-UI issue, not 
a technical one.)  You could
even not put up anything about the security level unless the protocol 
detected an attack or unless
the user's 3rd-party  verification tool agreed it was secure by some 
independent channel.

>> So between two RTCWEB browsers it would always be DTLS-SRTP.
> Agree.
Ditto

-- 
Randell Jesup
[e-mail]