draft-ietf-avtcore-srtp-vbr-audio-02.txt | draft-ietf-avtcore-srtp-vbr-audio-03.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: BCP JM. Valin | Intended status: BCP JM. Valin | |||
Expires: October 30, 2011 Octasic Inc. | Expires: January 7, 2012 Octasic Inc. | |||
April 28, 2011 | July 6, 2011 | |||
Guidelines for the use of Variable Bit Rate Audio with Secure RTP | Guidelines for the use of Variable Bit Rate Audio with Secure RTP | |||
draft-ietf-avtcore-srtp-vbr-audio-02.txt | draft-ietf-avtcore-srtp-vbr-audio-03.txt | |||
Abstract | Abstract | |||
This memo discusses potential security issues that arise when using | This memo discusses potential security issues that arise when using | |||
variable bit rate audio with the secure RTP profile. Guidelines to | variable bit rate audio with the secure RTP profile. Guidelines to | |||
mitigate these issues are suggested. | mitigate these issues are suggested. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 30, 2011. | This Internet-Draft will expire on January 7, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 4, line 11 ¶ | skipping to change at page 4, line 11 ¶ | |||
In practical SRTP scenarios, it must also be considered how | In practical SRTP scenarios, it must also be considered how | |||
significant the information leak is when compared to other SRTP- | significant the information leak is when compared to other SRTP- | |||
related information, such as the fact that the source and destination | related information, such as the fact that the source and destination | |||
IP addresses are available. | IP addresses are available. | |||
3. Guidelines for use of VBR Audio with SRTP | 3. Guidelines for use of VBR Audio with SRTP | |||
It is the responsibility of the application designer to determine the | It is the responsibility of the application designer to determine the | |||
appropriate trade-off between security and bandwidth overhead. As a | appropriate trade-off between security and bandwidth overhead. As a | |||
general rule, VBR codecs should be considered safe in the context of | general rule, VBR codecs should be considered safe in the context of | |||
encrypted one-to-one calls. However, applications that make use of | encrypted unstructured calls. However, applications that make use of | |||
pre-recorded messages where the contents of such pre-recorded | pre-recorded messages where the contents of such pre-recorded | |||
messages may be of any value to an evesdropper (i.e., messages beyond | messages may be of any value to an evesdropper (i.e., messages beyond | |||
standard greeting messages) SHOULD NOT use codecs in VBR mode. IVR | standard greeting messages) SHOULD NOT use codecs in VBR mode. | |||
applications would be particularly vulnerable since an evesdropper | Interactive voice response (IVR) applications would be particularly | |||
could easily use the rate information to easily recognize the prompts | vulnerable since an evesdropper could easily use the rate information | |||
being played out. | to easily recognize the prompts being played out. | |||
It is safe to use variable rate coding to adapt the output of a voice | It is safe to use variable rate coding to adapt the output of a voice | |||
codec to match characteristics of a network channel, for example for | codec to match characteristics of a network channel, for example for | |||
congestion control purposes, provided this adaptation done in a way | congestion control purposes, provided this adaptation done in a way | |||
that does not expose any information on the speech signal. That is, | that does not expose any information on the speech signal. That is, | |||
if the variation is driven by the available network bandwidth, not by | if the variation is driven by the available network bandwidth, not by | |||
the input speech (i.e., if the packet sizes and spacing are constant | the input speech (i.e., if the packet sizes and spacing are constant | |||
unless the network conditions change). VBR speech codecs can safely | unless the network conditions change). VBR speech codecs can safely | |||
be used in this fashion with SRTP while avoiding leaking information | be used in this fashion with SRTP while avoiding leaking information | |||
on the contents of the speech signal that might be useful for traffic | on the contents of the speech signal that might be useful for traffic | |||
skipping to change at page 4, line 42 ¶ | skipping to change at page 4, line 42 ¶ | |||
Many speech codecs employ some form of voice activity detection (VAD) | Many speech codecs employ some form of voice activity detection (VAD) | |||
to either suppress output frames, or generate some form of lower-rate | to either suppress output frames, or generate some form of lower-rate | |||
comfort noise frames, during periods when the speaker is not active. | comfort noise frames, during periods when the speaker is not active. | |||
If VAD is used on an encrypted speech signal, then some information | If VAD is used on an encrypted speech signal, then some information | |||
about the characteristics of that speech signal can be determined by | about the characteristics of that speech signal can be determined by | |||
watching the patterns of voice activity. This information leakage is | watching the patterns of voice activity. This information leakage is | |||
less than with VBR coding since there are only two rates possible. | less than with VBR coding since there are only two rates possible. | |||
The information leakage due to VAD in SRTP audio sessions can be much | The information leakage due to VAD in SRTP audio sessions can be much | |||
reduced if the sender adds an unpredictable "overhang" period to the | reduced if the sender adds an unpredictable "overhang" period to the | |||
end of active speech intervals, so obscuring their actual length. an | end of active speech intervals, so obscuring their actual length. An | |||
RTP sender using VAD with encrypted SRTP audio SHOULD insert such an | RTP sender using VAD with encrypted SRTP audio SHOULD insert such an | |||
overhang period at the end of each talkspurt, delaying the start of | overhang period at the end of each talkspurt, delaying the start of | |||
the silence/comfort noise by a random interval. The length of the | the silence/comfort noise by a random interval. The length of the | |||
overhang applied to each talkspurt must be randomly chosen in such a | overhang applied to each talkspurt must be randomly chosen in such a | |||
way that it is computationally infeasible for an attacker to reliably | way that it is computationally infeasible for an attacker to reliably | |||
estimate the length of that talkspurt. The audio data comprising the | estimate the length of that talkspurt. This may be more important | |||
overhang period must be packetised and transmitted in RTP packets in | for short talk spurts, since is seems easier to distinguish between | |||
a manner that is indistinguishable from the other data in the | different single word reponses based on the exact word length, than | |||
talkspurt. | to glean meaning from the duration of a longer phrase. The audio | |||
data comprising the overhang period must be packetised and | ||||
transmitted in RTP packets in a manner that is indistinguishable from | ||||
the other data in the talkspurt. | ||||
The overhang period SHOULD have an exponentially-decreasing | The overhang period SHOULD have an exponentially-decreasing | |||
probability distribution function. This ensures a long tail, while | probability distribution function. This ensures a long tail, while | |||
being easy to compute. It is RECOMMENDED to use an overhang with a | being easy to compute. It is RECOMMENDED to use an overhang with a | |||
"half life" of a few hundred milliseconds (this should be sufficient | "half life" of a few hundred milliseconds (this should be sufficient | |||
to obscure the presence of inter-word pauses and the lengths of | to obscure the presence of inter-word pauses and the lengths of | |||
single words spoken in isolation, for example the digits of a credit | single words spoken in isolation, for example the digits of a credit | |||
card number clearly enunciated for an automated system, but not so | card number clearly enunciated for an automated system, but not so | |||
long as to significantly reduce the effectiveness of VAD for | long as to significantly reduce the effectiveness of VAD for | |||
detecting listening pauses). Despite the overhang (and no matter | detecting listening pauses). Despite the overhang (and no matter | |||
End of changes. 7 change blocks. | ||||
14 lines changed or deleted | 17 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |