Re: [rtcweb] Resolving RTP/SDES question in Paris

[Roman Shpount <[e-mail]>]

On Mon, Mar 19, 2012 at 8:18 PM, Eric Rescorla <[e-mail]> wrote:

> As discussed in draft-ietf-rtcweb-security, I don't agree that DTLS-SRTP
> without
> identity and SDES-SRTP offer the same level of security. Most of what I
> have
> to say about that is already said there, but briefly:
>
> - DTLS-SRTP is secure against retrospective attack whereas SDES-SRTP is
> not.
> - If there is a mechanism such as fingerprints *is* available for
> checking against
> MITM, then DTLS-SRTP is secure against active attack as well. Additionally,
> the existence of fingerprint type mechanisms acts as a partial deterrent
> against
> MITM attack by the signaling provider even if only a small number of people
> check.
>
>
I agree with you on all of those points. I would prefer that instead of
SDES SRTP support we spent time optimizing DTLS/ICE handshake (and there
are a few drafts on this list related to that). It should be possible to
conduct a secure key exchange at the same time as ICE candidate selection
with no additional overhead. I also understand the argument that most of
the regular users will never check the fingerprint, and this is why I put
SDES-SRTP and DTLS-SRTP in the same group. DTLS-SRTP is more secure then
SDES-SRTP, but it still not enough to tell the user that communication is
secure.

But regardless of all these points, if we allow signaling over HTTP all the
security considerations go out of the window.

For me the ideal solution is:

1. DTLS-SRTP with Identity and any signaling is always allowed and shows
notification that communication is with a known party and secure.
2. DTLS-SRTP with signaling over HTTPS shows notification that
communication is unsecure and with an unknown party
3. SDES SRTP is not supported at all and DTLS/ICE handshake is optimized
instead to reduce call setup time
4. DTLS-SRTP with no ident and RTP with signaling over HTTP are not
recommended, but allowed after a big red sign (or require some advanced
browser setting to enable).

I would also like to have a simplified DTLS specification for DTLS-SRTP,
with as many as possible unnecessary features (encryption algorithms,
cookies and such) removed and only a few required scenarios supported. For
instance, I do not want DTLS on a WebRTC channel start negotiation and end
up with anything except SRTP as an encryption protocol. Ideally, I want
something were an interop test can be developed with a manageable number of
scenarios.

P.S. Sending RSA public key in the session description instead of
fingerprint and then encrypting the SRTP key using this public key and
sending it in the ICE message might be a much simpler call setup mechanism
to implement then bringing the whole DTLS into the stack. This should also
allow us to setup a secure call with no overhead in addition to ICE.
_____________
Roman Shpount