RFC 6562

RFC 6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP 🎀

Okay bestie, this one is a Standards Track doc from the IETF, dated March 2012 📅. It was written by C. Perkins (University of Glasgow) and JM. Valin (Mozilla Corporation), and it's published under ISSN 2070-1721 ✨. This title block doesn't list any Obsoletes or Updates line, so it doesn't say that it replaces or changes any other RFC 💅.

Abstract

So the abstract is giving: this memo looks at the security issues that pop up when you use variable bit rate (VBR) audio with the secure RTP profile 🔐. It also suggests guidelines to help mitigate those issues 🛡️.

Status of This Memo

This is an Internet Standards Track document 🦋.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. If you want more on Internet Standards, check out Section 2 of RFC 5741 📖.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6562 🌸.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🧾.

Table of Contents

1.  Introduction ...................................................2
2.  Scenario-Dependent Risk ........................................2
3.  Guidelines for Use of VBR Audio with SRTP ......................3
4.  Guidelines for Use of Voice Activity Detection with SRTP .......3
5.  Padding the Output of VBR Codecs ...............................4
6.  Security Considerations ........................................5
7.  Acknowledgements ...............................................5
8.  References .....................................................5
    8.1. Normative References ......................................5
    8.2. Informative References ....................................6

1. Introduction ✨

Okay so the Secure RTP (SRTP) framework [RFC3711] is a widely used way to secure RTP sessions [RFC3550] 🔒. SRTP lets you encrypt the payload of an RTP packet and optionally add an authentication tag, while the RTP header and any header extension stay in the clear 👀. There are a bunch of encryption transforms you can use with SRTP, but none of the predefined ones use any padding, so the RTP and SRTP payload sizes match exactly 📏.

Here's the tea 🍵: when you use SRTP with voice streams compressed by variable bit rate (VBR) codecs, the length of the compressed packets depends on the characteristics of the speech signal 🎙️. That variation in packet size leaks a little bit of information about what's being said, and for some apps that's a real security risk 😬. For example, [spot-me] shows that known phrases in an encrypted call using the Speex codec in VBR mode can be recognized with high accuracy in certain circumstances 🎯. And [fon-iks] shows that approximate transcripts of encrypted VBR calls can be derived for some codecs without breaking the encryption 🫣. How big these results are, and how they carry over to other codecs, is still an open question 🤔. This memo talks about ways to mitigate these traffic analysis risks 🛡️.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📚.

2. Scenario-Dependent Risk 🎭

Whether the leaks and attacks from [spot-me], [fon-iks], and similar works matter really depends on the app and the use scenario 💭. In the worst case, if someone knows the full set of possible prerecorded messages, using the rate information to recognize one of them would lead to near-perfect accuracy 😱. Even when the audio isn't prerecorded, it's possible to recognize contents from encrypted audio when the dialog is highly structured. For example, if the eavesdropper knows only a handful of possible sentences can be said, then the dialog contains very little information 🧩. Recognizing unconstrained conversational speech from the rate information alone is unreliable and computationally expensive right now, but it does seem possible in some circumstances 🌀. These attacks are only likely to get better over time 📈.

In real SRTP setups, you have to compare how big the information leak is with other SRTP-related information, like the fact that the source and destination IP addresses are visible 👀.

3. Guidelines for Use of VBR Audio with SRTP 💖

It's up to the application designer to pick the right balance between security and bandwidth overhead 🎀. As a general rule, VBR codecs should be considered safe for low-value encrypted unstructured calls 🌸. But apps that play prerecorded messages where those messages could be worth something to an eavesdropper (so, anything beyond standard greetings) SHOULD NOT use codecs in VBR mode 🚫. Interactive voice response (IVR) apps are especially vulnerable, since an eavesdropper could easily use the rate information to figure out which prompts are being played 📞. Apps that carry highly sensitive unstructured information SHOULD NOT use codecs in VBR mode either 🔐.

It's safe to use variable rate coding to adapt a voice codec's output to match a network channel, as long as the adaptation doesn't expose any information about the speech signal 🌈. For example, VBR audio can be used for congestion control, where the variation is driven by the available network bandwidth and not by the input speech. In that case the packet sizes and spacing stay constant unless network conditions change 📶. VBR speech codecs can safely be used this way with SRTP, and they avoid leaking speech-content information that traffic analysis could use 🧚.

4. Guidelines for Use of Voice Activity Detection with SRTP 🤫

Lots of speech codecs use some form of voice activity detection (VAD) to either suppress output frames or generate lower-rate comfort noise frames while the speaker isn't talking 🎧. If VAD is used on an encrypted speech signal, then someone watching the patterns of voice activity can learn something about the characteristics of that speech signal 👁️. This leak is smaller than with VBR coding, since there are only two rates possible 🙈.

You can cut down the information leak from VAD in SRTP audio sessions a lot by having the sender add an unpredictable "overhang" period to the end of active speech intervals, which hides how long they really are 🫥. An RTP sender using VAD with encrypted SRTP audio SHOULD insert an overhang period at the end of each talkspurt, which delays the start of the silence or comfort noise by a random interval ⏳. The length of the overhang for each talkspurt must be picked randomly, in a way that makes it computationally infeasible for an attacker to reliably estimate how long the talkspurt was 🎲. This matters more for short talkspurts, since it's easier to tell apart single-word responses by their exact length than to get meaning from the duration of a longer phrase 🍓. The audio in the overhang period must be packetized and sent in RTP packets in a way that can't be told apart from the rest of the talkspurt's data 🥷.

The overhang period SHOULD have an exponentially decreasing probability distribution function 📉. This gives you a long tail and is easy to compute ✨. It is RECOMMENDED to use an overhang with a "half life" of a few hundred milliseconds 🍃. That should be enough to hide interword pauses and the lengths of single words said on their own, like the digits of a credit card number read out clearly to an automated system 💳. It shouldn't be so long that it seriously weakens VAD at detecting listening pauses 👂. Even with the overhang (and no matter how long it is), a small amount of information still leaks about the start time of the talkspurt. That's because putting an overhang on the start of a talkspurt would hurt intelligibility too much 😵‍💫. For that reason, VAD SHOULD NOT be used in encrypted IVR applications where the content of prerecorded messages may be of any value to an eavesdropper 🚫📞.

Adding a random overhang to each talkspurt does make VAD less effective in SRTP sessions than in non-SRTP sessions 📉. Still, VAD is expected to give significant bandwidth savings for many encrypted sessions 💅.

5. Padding the Output of VBR Codecs 🎁

When VBR is considered unsafe, a constant bit rate (CBR) codec SHOULD be negotiated and used instead, or the VBR codec SHOULD be run in a CBR mode 🔁. But if the codec doesn't support CBR, RTP padding SHOULD be used to shrink the information leak to an insignificant level 🧽. Packets can be padded to one constant size, or to a small range of sizes ([spot-me] gets good results by padding to the next multiple of 16 octets, but how much padding you need to hide the size variation depends on the codec and how sophisticated the attacker is 🕵️). They can also be padded to a size that changes over time 🕰️. The most secure and RECOMMENDED option is to pad all packets throughout the call to the same size 🏆.

If the size of the padded packets changes over time, the same concerns as with VAD apply 🔄. So the padding SHOULD NOT be reduced without waiting a certain random amount of time 🫧. The RECOMMENDED "hold time" is the same as the one for VAD ⏱️.

Note that SRTP encrypts the count of the octets of padding added to a packet, but it doesn't encrypt the bit in the RTP header that says the packet has been padded 👀. Because of that, it is RECOMMENDED to add at least one octet of padding to all packets in a media stream, so an attacker can't tell which packets needed padding 🫣.

6. Security Considerations 🔐

Literally this whole memo is about security 😭. The security considerations of [RFC3711] also apply, so don't skip them, bestie 💀.

7. Acknowledgements 🫶

ZRTP [RFC6189] has similar recommendations 🎶. The point of this memo is to bring these issues to a wider audience, since they aren't specific to ZRTP 📣. Huge thanks to Phil Zimmermann, Stefan Doehla, Mats Naslund, Gregory Maxwell, David McGrew, Mark Baugher, Koen Vos, Ingemar Johansson, and Stephen Farrell for their comments and feedback on this memo 💜.

8. References 📚

8.1. Normative References ✨

Okay bestie, these are the must-read homework 📚 because this doc literally can't be understood without them 🫶

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
• [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

8.2. Informative References 🦋

These ones are the bonus reading, the "ooh tell me more" stuff 💅 You don't need them to follow along, but they're iconic 🔥

• [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, April 2011.
• [fon-iks] White, A., Matthews, A., Snow, K., and F. Monrose, "Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on fon-iks", Proceedings of the IEEE Symposium on Security and Privacy 2011, May 2011.
• [spot-me] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversation", Proceedings of the IEEE Symposium on Security and Privacy 2008, May 2008.

---

Authors' Addresses 🌸

Meet the brains behind the whole thing 🧚 Here's where you can find them, no cap:

Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
UK

EMail: csp@csperkins.org


Jean-Marc Valin
Mozilla Corporation
650 Castro Street
Mountain View, CA  94041
USA

Phone: +1 650 903-0800
EMail: jmvalin@jmvalin.ca

That's the whole doc, bestie! 🌈👑 Go be a main character 💖