Re: [rtcweb] Consensus call regarding media security

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Roman Shpount
> Sent: Wednesday, March 28, 2012 6:15 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [rtcweb] Consensus call regarding media security
> 
> Igor,
> 
> I could not attend the meeting today, but I am responding to the call
> of consent on the list, that did not mention that or any other
> conditions on SRTP encryption support. Does it also mean that the call
> can be established using plain RTP, or is DTLS handshake, even in order
> to setup NULL encruption, is still a requirement? If DTLS handshake is
> a requirement, I still would object to it, since this will require an
> extra implementation and interop step in anything communicating with
> WebRTC.

The opposite it also true.

Specifically, if Security Descriptions is required for RTCWEB endpoints,
it requires extra implementation and interop for all RTCWEB endpoints.

> On the related note, where is SRTP profile with NULL encoding defined?
> I have seen quite a few SRTP implementations but not a single one of
> them supported NULL codec in any of its profiles.  Also, we should be
> very careful not to support NULL encoding unless it is specifically
> enabled in API. Even though I do want to support unencrypted media, I
> do not want anything that allows to bid down from encrypted to
> unencrypted connection, for instance during DTLS negotiation, unless
> specifically enabled.

During their (D)TLS handshake, the (D)TLS client and server exchange
a list of cipher suites they support, and use the strongest supported
by both the client and server.  To negotiate Null, the ClientHello needs
to include the Null cipher suite and the (D)TLS server needs to choose 
Null -- if its policy allows choosing Null.  A (D)TLS server will 
usually not allow negotiating Null, and a (D)TLS client will usually 
not include Null in its list of cipher suites.

-d

> _____________
> Roman Shpount
> 
> 
> 
> On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg <igor.faynberg@alcatel-
> lucent.com> wrote:
> 
> 
> 
> 	Roman,
> 
> 	I think there is a misunderstanding (I assume you did not attend
> the meeting today).  It has been clarified that SRTP allows the NULL
> encryption algorithm, and that this option will be available.
> 
> 	Igor
> 
> 
> 	On 3/28/2012 11:49 AM, Roman Shpount wrote:
> 
> 		As I have mentioned before on this list I am strongly
> against making SRTP protection for RTP a requirement. I think this is
> an unnecessary requirement that serves little real purpose except
> feeding into some marketing message that most of the WebRTC users would
> not care about. Unless use of identity is also a requirement, requiring
> SRTP will provide security only in a very narrow sense of the word. At
> the same time I do believe that extra standard requirements will stifle
> innovation and  will complicate new service or application creation.
> 
> 		I have no objection to making DTLS-SRTP a required to
> implement protocol.
> 		_____________
> 		Roman Shpount
> 
> 
> 
> 		On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund
> <[e-mail]> 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
> 
> 			_______________________________________________
> 			rtcweb mailing list
> 			[e-mail]
> 			https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> 
> 		_______________________________________________
> 		rtcweb mailing list
> 		[e-mail]
> 		https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 	_______________________________________________
> 	rtcweb mailing list
> 	[e-mail]
> 	https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
>