Set DtlsSrtpKeyAgreement to mandatory MediaConstraints

[Павел Крахалев]

Our security audit noticed that DtlsSrtpKeyAgreement has been used as optional MediaConstraints. 
We have added it to mandatory constraints, but sometimes connection cannot be established - we receive empty sdp.

I see that in WebRTC demo app this constraint uses as mandatory, but for us it works only if I set RtpDataChannels parameter to optional as well. 
I have found this solution in this review, where both parameters have been set - https://review.webrtc.org/10749004/patch/1/2

Could you please tell us how we should use the DtlsSrtpKeyAgreement. Is it supported to be mandatory and why it requires RtpDataChannels patameter in the optional then?

[Harald Alvestrand]

SrtpKeyAgreement is a MUST NOT in the standard; it profoundly reduces the security of your conversations.

In addition, SrtpKeyAgreement means that SCTP based datachannels are unusable (they depend on proper DTLS), so in order to use SrtpKeyAgreement, you either can't use datachannels, or you have to use the ancient RTP-based datachannels (which don't have the same functionality).

In short: If you want to use SrtpKeyAgreement - don't.

(Its presence in demos is an embarassment, and should be fixed.)

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b2dfc088-2dd4-4d8a-90f8-075e539f4143%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Павел Крахалев]

I have made some tests without SrtpKeyAgreement, but without the property our application could not establish connection with the old version which uses SrtpKeyAgreement. What about backward compatibility?

SrtpKeyAgreement is a MUST NOT in the standard; it profoundly reduces the security of your conversations.

In addition, SrtpKeyAgreement means that SCTP based datachannels are unusable (they depend on proper DTLS), so in order to use SrtpKeyAgreement, you either can't use datachannels, or you have to use the ancient RTP-based datachannels (which don't have the same functionality).

In short: If you want to use SrtpKeyAgreement - don't.

(Its presence in demos is an embarassment, and should be fixed.)

On Mon, Jan 15, 2018 at 2:06 PM, Павел Крахалев <kpav...@gmail.com> wrote:

Our security audit noticed that DtlsSrtpKeyAgreement has been used as optional MediaConstraints. 
We have added it to mandatory constraints, but sometimes connection cannot be established - we receive empty sdp.

I see that in WebRTC demo app this constraint uses as mandatory, but for us it works only if I set RtpDataChannels parameter to optional as well. 
I have found this solution in this review, where both parameters have been set - https://review.webrtc.org/10749004/patch/1/2

Could you please tell us how we should use the DtlsSrtpKeyAgreement. Is it supported to be mandatory and why it requires RtpDataChannels patameter in the optional then?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Harald Alvestrand]

The decision to remove SRTPKeyAgreement from the standards was made back in 2013:

https://www.ietf.org/mail-archive/////web/rtcweb/current/msg08646.html

You have the source, and the ability to check out any previous version from the repository, so if you need more than 5 years to make the transition to better security, you can make it work.

(In fact it will work in current code - as you note, it requires the use of RTP data channels or no data channels, but will work.)

I do recommend getting rid of it ASAP.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d33cb0e7-e626-4de2-b788-6dad22047808%40googlegroups.com.

[Павел Крахалев]

Thanks for the information. Could you please update Demo app to align with this requirements.

[Harald Alvestrand]

On investigating further:

The mode that is a security hazard is actually explicitly setting
DtlsSrtpKeyAgreement to false, which will invoke the older SDES key
agreement - the one that got banned. I misremembered its name.

Setting DtlsSrtpKeyAgreement to true should have no effect, because
that's the default.

> <https://groups.google.com/d/msgid/discuss-webrtc/b2dfc088-2dd4-4d8a-90f8-075e539f4143%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit
> https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
>
> ---
> You received this message because you are subscribed to the
> Google Groups "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to discuss-webrt...@googlegroups.com

> <javascript:>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/discuss-webrtc/d33cb0e7-e626-4de2-b788-6dad22047808%40googlegroups.com
> <https://groups.google.com/d/msgid/discuss-webrtc/d33cb0e7-e626-4de2-b788-6dad22047808%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to discuss-webrt...@googlegroups.com

> <mailto:discuss-webrt...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/discuss-webrtc/80382711-836a-4605-b323-cbc6a7ad48ba%40googlegroups.com
> <https://groups.google.com/d/msgid/discuss-webrtc/80382711-836a-4605-b323-cbc6a7ad48ba%40googlegroups.com?utm_medium=email&utm_source=footer>.