datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

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

Internet Engineering Task Force (IETF)                        C. Perkins
Request for Comments: 6562                         University of Glasgow
Category: Standards Track                                      JM. Valin
ISSN: 2070-1721                                      Mozilla Corporation
                                                              March 2012

                       Guidelines for the Use of
                Variable Bit Rate Audio with Secure RTP

Abstract

   This memo discusses potential security issues that arise when using
   variable bit rate (VBR) audio with the secure RTP profile.
   Guidelines to mitigate these issues are suggested.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to 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 are provided without warranty as
   described in the Simplified BSD License.

Perkins & Valin              Standards Track                    [Page 1]
RFC 6562                   VBR Audio with SRTP                March 2012

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

   The Secure RTP (SRTP) framework [RFC3711] is a widely used framework
   for securing RTP sessions [RFC3550].  SRTP provides the ability to
   encrypt the payload of an RTP packet, and optionally add an
   authentication tag, while leaving the RTP header and any header
   extension in the clear.  A range of encryption transforms can be used
   with SRTP, but none of the predefined encryption transforms use any
   padding; the RTP and SRTP payload sizes match exactly.

   When using SRTP with voice streams compressed using variable bit rate
   (VBR) codecs, the length of the compressed packets will depend on the
   characteristics of the speech signal.  This variation in packet size
   will leak a small amount of information about the contents of the
   speech signal.  This is potentially a security risk for some
   applications.  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 significant these
   results are, and how they generalize to other codecs, is still an
   open question.  This memo discusses ways in which such traffic
   analysis risks may be mitigated.

   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 information leaks and attacks discussed in [spot-me],
   [fon-iks], and similar works are significant is highly dependent on
   the application and use scenario.  In the worst case, using the rate
   information to recognize a prerecorded message knowing the set of all

[include full document text]