Re: [rtcweb] Consensus call regarding media security

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Basil Mohamed Gohar
> Sent: Wednesday, March 28, 2012 4:55 PM
> To: [e-mail]
> Subject: Re: [rtcweb] Consensus call regarding media security
> 
> On 03/28/2012 10:50 AM, Magnus Westerlund wrote:
> > WG,
> >
> > In todays RTCWEB WG meeting there was discussion around media
> security
> > mechanism. In this meeting there was some clear consensus in the
> > meeting which we would like to confirm on the list.
> >
> > The first was that there was overwhelming consensus that all RTP
> > packets SHALL be protected by SRTP.
> >
> > Secondly that no one objected against making DTLS-SRTP a mandatory to
> > implement and the default keying mechanism. Additional mechanisms are
> > not precluded.
> >
> > WG participants may state their position regarding these consensus
> calls
> > until 12th of April when the chairs will declare the final consensus.
> If
> > you where present in the meeting room and comment on this, please
> > indicate that.
> >
> > Best Regards
> >
> > Magnus Westerlund
> > For the WG chairs
> I already brought-up my concerns in the other thread, so I'll summarize
> the core point I was making here.  Would using SRTP *require* a central
> authority for establishing authenticity, or can authenticity be
> established via a point-to-point means (e.g., how it's traditionally
> done via SSH [i.e., upon first connection or via previous key
> exchange])?

A central authority is not required.

DTLS-SRTP itself doesn't use the information in the DTLS certificates (the
information that might be present is ignored).  

Of course, if you want identity, then an identity service needs to exist.
But it is possible to operate DTLS-SRTP without identity, which still
provides value beyond Security Descriptions.  For example, because you
mentioned ssh, an 'easy' way to do DTLS-SRTP is to place the remote
peer's certificate fingerprint into your local address book.  No central
authority is needed, and you could get an alert if/when the remote peer's 
certificate changes.  A similar technique for HTTP is described in 
draft-ietf-websec-key-pinning.  A similar technique for ZRTP is
http://tools.ietf.org/html/rfc6189#section-12.

> This is about degrees of trust that the user is will to place upon
> various methods, of course.  I am stating that the option should exist
> for authenticity of an end point to be established outside of a central
> authority (e.g., key exchange via other means).

I agree that is valuable.

-d