PSA: Default SRTP authentication tag length changing from 32 to 80 bits
Taylor Brandstetter
Summary
We're changing to a more secure DTLS-SRTP profile (SRTP_AES128_CM_HMAC_SHA1_80), which uses an 80-bit authentication tag as recommended by the SRTP standard.
Aside from adding 6 bytes per packet, this is not expected to have any adverse effects. This change hasn't landed yet, but is expected to hit Chrome M67.
Background/Details
Historically, we only intended to use the 32-bit tag for audio streams, where the security trade-off is more acceptable than for video.
However, when audio and video are "bundled" on the same DTLS association (indicated by "a=group:BUNDLE audio video" in SDP), they're forced to use the same DTLS-SRTP profile. Meaning that video streams were forced to use a 32-bit tag when bundled with audio.
We're addressing this by removing SRTP_AES128_CM_HMAC_SHA1_32 from the set of negotiated DTLS-SRTP protection profiles, leaving only SRTP_AES128_CM_HMAC_SHA1_80, for which the WebRTC Security Architecture spec mandates support.
For more information about the tradeoffs between the 32-bit and 80-bit tag, see RFC3711 S 7.5.
Opting in to 32-bit tag
For situations where the security tradeoff is acceptable, native applications can opt in to using the 32-bit tag, using:
C++: enable_aes128_sha1_32_crypto_cipher (in PeerConnectionFactoryInterface::Options::crypto_options)
Objective-C: enableAes128Sha1_32CryptoCipher
Web applications, however, will be forced to use the 80-bit tag.
Simon Perreault
Historically, we only intended to use the 32-bit tag for audio streams, where the security trade-off is more acceptable than for video.
Harald Alvestrand
Hey Taylor,
2018-04-03 19:11 GMT-04:00 'Taylor Brandstetter' via discuss-webrtc <discuss-webrtc@googlegroups.com>:Historically, we only intended to use the 32-bit tag for audio streams, where the security trade-off is more acceptable than for video.
Out of curiosity, can you explain this in a little bit more detail? Is it about video content being more "sensitive" than audio? Or is it simply the fact that there's usually more video data than audio? Or something else?Thanks,Simon
--
---
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/CANO7kWANpoGcRntt-osJYEo0XBGMBcvr7C9jkJzR-WHbVJYooQ%40mail.gmail.com.
Simon Perreault
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVEQ3aqG_0OTQ65bYB1Fd5DbS-yqjvLvPx%2BwAQtBwNgRJA%40mail.gmail.com.
Basar Daldal
On Thursday, April 5, 2018 at 12:04:57 AM UTC+3, Simon Perreault wrote:
Makes total sense, thanks!Simon
2018-04-04 8:53 GMT-04:00 'Harald Alvestrand' via discuss-webrtc <discuss...@googlegroups.com>:
Audio packets are smaller than video packets, so the extra 6 bytes represent a larger percentage overhead for audio than it does for video.This was the common view 10 years ago (the registering RFC, https://tools.ietf.org/html/rfc5764, is from 2010, with its first official draft published in 2007); today I think the extra 6 bytes are seen as a manageable cost.
On Wed, Apr 4, 2018 at 1:24 PM, Simon Perreault <sperr...@jive.com> wrote:
Hey Taylor,
2018-04-03 19:11 GMT-04:00 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com>:Historically, we only intended to use the 32-bit tag for audio streams, where the security trade-off is more acceptable than for video.
Out of curiosity, can you explain this in a little bit more detail? Is it about video content being more "sensitive" than audio? Or is it simply the fact that there's usually more video data than audio? Or something else?Thanks,Simon
--
---
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANO7kWANpoGcRntt-osJYEo0XBGMBcvr7C9jkJzR-WHbVJYooQ%40mail.gmail.com.
--
---
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.
Taylor Brandstetter
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/ee1b26e2-9af8-4690-af2e-79d3e92b400c%40googlegroups.com.