Subject: [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 5 Mar 2009 23:43:23 +0000

I've submitted the following draft, discussing the potential issues  
that can arise when using VBR audio with SRTP. This is a  
generalisation of the advice included in recent versions of ZRTP,  
since it's not ZRTP specific.  Comments welcome.

Colin

Begin forwarded message:
> From: [email-masked]
> Date: 5 March 2009 01:00:01 GMT
> To: [email-masked]
> Subject: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Guidelines for the use of Variable Bit Rate  
> Audio with Secure RTP
> 	Author(s)       : C. Perkins
> 	Filename        : draft-perkins-avt-srtp-vbr-audio-00.txt
> 	Pages           : 5
> 	Date            : 2009-03-04
>
> This memo discusses potential security issues that arise when using
> variable bit rate audio with the secure RTP profile.  Guidelines to
> mitigate these issues are suggested.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avt-srtp-vbr- 
> audio-00.txt

-- 
Colin Perkins
http://csperkins.org/

---

From: Stefan Döhla <[email-masked]>
Date: Fri, 06 Mar 2009 10:51:47 +0100

Hi Colin,

that's an interesting topic, however I think the recommendation to not 
use SRTP with VBR audio codecs is a little too strong.

The security problem arises especially with VBR speech codecs (not VBR 
audio codecs in general!) and is probably very codec specific. Also the 
solution is imho not too deprecate encryption with VBR codecs but more 
to introduce a padding mechanism within SRTP/ZRTP, e.g. either padding 
to multiples of a certain value or random padding if the codec doesn't 
support/hasn't used padding internally already.

Cheers
- Stefan

Colin Perkins schrieb:
>> http://www.ietf.org/internet-drafts/draft-perkins-avt-srtp-vbr-audio-00.txt 
>>
>
>

-- 
Dipl.-Ing. Stefan Döhla     | Email: [email-masked]
Multimedia Transport        | Phone: +49 (0)9131 776 6042 (!NEW!)
Audio Department            | Fax:   +49 (0)9131 776 6099 (!NEW!)
Fraunhofer IIS              |
Am Wolfmantel 33            |
91058 Erlangen, Germany     | Web:   http://www.iis.fraunhofer.de/amm

---

From: Colin Perkins <[email-masked]>
Date: Fri, 6 Mar 2009 10:37:13 +0000

Hi Stefan,

There is such a padding mechanism in RTP already, and my first  
iteration of this draft had a recommendation to use it in much the  
way you suggest. That recommendation was removed because of the  
warnings about using padding with SRTP and certain encryption  
transforms (section 3.1 of RFC 3711). From my (limited) understanding  
of the attack referenced there, the default transforms should be  
safe, so maybe we can relax the recommendation in that case, and  
recommend padding to a fixed size?

Re audio vs speech; this is specifically intended for VBR coded  
speech as you note. If I accidentally said VBR audio, that should be  
corrected.

Colin

On 6 Mar 2009, at 09:51, Stefan Döhla wrote:
> Hi Colin,
>
> that's an interesting topic, however I think the recommendation to  
> not use SRTP with VBR audio codecs is a little too strong.
>
> The security problem arises especially with VBR speech codecs (not  
> VBR audio codecs in general!) and is probably very codec specific.  
> Also the solution is imho not too deprecate encryption with VBR  
> codecs but more to introduce a padding mechanism within SRTP/ZRTP,  
> e.g. either padding to multiples of a certain value or random  
> padding if the codec doesn't support/hasn't used padding internally  
> already.
>
> Cheers
> - Stefan
>
> Colin Perkins schrieb:
>> I've submitted the following draft, discussing the potential  
>> issues that can arise when using VBR audio with SRTP. This is a  
>>> A New Internet-Draft is available from the on-line Internet- 
>>> Drafts directories.
>>>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Mats Näslund <[email-masked]>
Date: Fri, 6 Mar 2009 13:24:02 +0100

Hi Colin,

I think it is good to issue this kind of warning. But from what I now
understand from the thread below, the issue seems quite general, i.e. 
very few (if any) security protocol would be able to secure VBR in a 
sufficient way.
 
When I first read the draft, I somehow get the impression that the problem 
Is mainly related to usage of _SRTP_, but it seems it is more general(?)

So, shouldn't it be rephrased as general caveat when seeking
to protect VBR?

Best,

/Mats 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Colin Perkins
> Sent: den 6 mars 2009 11:37
> To: Stefan Döhla
> Cc: [email-masked] WG
> Subject: Re: [AVT] Fwd: I-D 
> Action:draft-perkins-avt-srtp-vbr-audio-00.txt
> 
> Hi Stefan,
> 
> There is such a padding mechanism in RTP already, and my 
> first iteration of this draft had a recommendation to use it 
> in much the way you suggest. That recommendation was removed 
> because of the warnings about using padding with SRTP and 
> certain encryption transforms (section 3.1 of RFC 3711). From 
> my (limited) understanding of the attack referenced there, 
> the default transforms should be safe, so maybe we can relax 
> the recommendation in that case, and recommend padding to a 
> fixed size?
> 
> Re audio vs speech; this is specifically intended for VBR 
> coded speech as you note. If I accidentally said VBR audio, 
> that should be corrected.
> 
> Colin
> 
> 
> 
> > audio codecs in general!) and is probably very codec specific.
> > Also the solution is imho not too deprecate encryption with 
> VBR codecs 
> > but more to introduce a padding mechanism within SRTP/ZRTP, e.g. 
> > either padding to multiples of a certain value or random padding if 
> > the codec doesn't support/hasn't used padding internally already.
> >
> > Cheers
> > - Stefan
> >
> > Colin Perkins schrieb:
> >>> A New Internet-Draft is available from the on-line 
> Internet- Drafts 
> >>> directories.
> >>>

---

From: "Jean-Marc Valin" <[email-masked]>
Date: Fri, 6 Mar 2009 09:42:36 -0500

Hi Colin, Mats,

I think all this may be a little premature, considering that only one codec was analysed: Speex. While it's flattering as the author of Speex that there is an assumption that Speex VBR is like every other codecs's VBR, that remains to be confirmed (the fundamental cause of the leak has not been explained). Regarding padding, I think it simply defeats the purpose of VBR. Speex will *by default* produce a CBR stream and that is already the recommended way of using it for VoIP -- not because of privacy, but for real-time considerations (you can't afford buffering). With that in mind, it's a bit pointless quality-wise to change Speex to VBR and then pad to a constant packet length. I'm not aware of any speech codec that does not have a CBR mode (thought there may be some I'm not aware of). The only valid use of VBR I can think of for VoIP is when aggregating traffic, in which case and information contained in the VBR would be lost in the aggregation.

Mats, regarding your comment about banning VBR from non-secure streams as well, I think it's a bit pointless since any person who can see the packet lengths, can almost certainly see the packet content as well.

Cheers,

    Jean-Marc

-------- Message d'origine--------
De: [email-masked] de la part de Mats Näslund
Date: ven. 06/03/2009 07:24
À: Colin Perkins; Stefan Döhla
Cc: [email-masked]
Objet : Re: [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt
 
Hi Colin,

Best,

/Mats

---

From: Mats Näslund <[email-masked]>
Date: Fri, 6 Mar 2009 16:15:03 +0100

Hi Jean-Marc,
 
I have _not_ made any comment that I'd like to ban VBR. I am pretty sure it _can_ be secured but
it seems from the discussion that you need to make special considerations. 
 
/Mats

________________________________

	From: Jean-Marc Valin [mailto:[email-masked]] 
	Sent: den 6 mars 2009 15:43
	To: Mats Näslund; Colin Perkins; Stefan Döhla
	Cc: [email-masked]
	Subject: RE : [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt

	Hi Colin, Mats,

	
	Cheers,
	
	    Jean-Marc

	-------- Message d'origine--------
	De: [email-masked] de la part de Mats Näslund
	Date: ven. 06/03/2009 07:24
	À: Colin Perkins; Stefan Döhla
	Cc: [email-masked]
	Objet : Re: [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt
	
	Hi Colin,

	

	Best,
	
	/Mats

---

From: Mark Baugher <[email-masked]>
Date: Fri, 6 Mar 2009 08:17:43 -0800

hi Mats
   Do you think it can be secured without sacrificing the extremely  
low data-rate properties of VBR?

Mark

On Mar 6, 2009, at 7:15 AM, Mats Näslund wrote:

> I think all this may be a little premature, considering that only  
> one codec was analysed: Speex. While it's flattering as the author  
> of Speex that there is an assumption that Speex VBR is like every  
> other codecs's VBR, that remains to be confirmed (the fundamental  
> cause of the leak has not been explained). Regarding padding, I  
> think it simply defeats the purpose of VBR. Speex will *by default*  
> produce a CBR stream and that is already the recommended way of  
> using it for VoIP -- not because of privacy, but for real-time  
> considerations (you can't afford buffering). With that in mind, it's  
> a bit pointless quality-wise to change Speex to VBR and then pad to  
> a constant packet length. I'm not aware of any speech codec that  
> does not have a CBR mode (thought there may be some I'm not aware  
> of). The only valid use of VBR I can think of for VoIP is when  
> aggregating traffic, in which case and information contained in the  
> VBR would be lost in the aggregation.
>
> Mats, regarding your comment about banning VBR from non-secure  
> streams as well, I think it's a bit pointless since any person who  
> can see the packet lengths, can almost certainly see the packet  
> content as well.
>
> Cheers,
>
>     Jean-Marc
>
>

---

From: Gregory Maxwell <[email-masked]>
Date: Fri, 6 Mar 2009 17:19:26 -0500

On Fri, Mar 6, 2009 at 4:51 AM, Stefan Döhla
<[email-masked]> wrote:
[snip]
> The security problem arises especially with VBR speech codecs (not VBR audio
> codecs in general!) and is probably very codec specific. Also the solution
> is imho not too deprecate encryption with VBR codecs but more to introduce a
> padding mechanism within SRTP/ZRTP, e.g. either padding to multiples of a
> certain value or random padding if the codec doesn't support/hasn't used
> padding internally already.

Pad to "some amount but not enough to make it a constant rate" is not a good
security recommendation.

We can say with certainty that a constant size has no length related leaks.
Beyond that everything else is guesswork. This has been a well studied problem
for anonymous text relay networks, and its completely unsolved there.

The problem is that while some amount of size quantization may be suffificent
to thwart one attack there is no reason to believe that the countermeasure can
not be defeated by simply applying a more sophisticated analysis, or auditing
more data over time.

If the length related information leaks are of concern for your threat model
you must ensure that the length is not related to the content.

This is true for speech and general audio codecs since even the most simplistic
length->content relation will likely disclose a low resolution view of the
'activity level' of the channel.  Patterns of activity alone are enough to
distinguish languages to some degree.

The text I wrote on this subject for draft-valin-celt-rtp-profile-00.txt,
prior to seeing this recommendation document is:

   Because this format supports VBR operation small amounts of
   information about the transmitted audio may be leaked by a length
   preserving cryptographic transport.  Accordingly, when CELT is used
   inside a secure transport the sender SHOULD restrict the use of VBR
   to congestion control purposes.

   CELT implementations will typically exhibit tiny content-sensitive
   encoding time variances.  Since transmission is usually triggered by
   an accurate hardware clock and the encoded data is typically
   transmitted as soon as encoding is complete this variance may result
   in a small amount of additional frame to frame jitter which could be
   measured by a third-party.  Encrypted implementations SHOULD transmit
   packets at fixed intervals to avoid the possible information leak.

---

From: Mats Näslund <[email-masked]>
Date: Mon, 9 Mar 2009 10:14:06 +0100

Hi Mark,
 
I think David's analysis in the other mail is correct and that (sufficient amount of) padding + authentication can fix this.
So, there will be a penalty since both padding and authenticaton will contribute to making the packets larger.
 
/Mats

	From: Mark Baugher [mailto:[email-masked]] 
	Sent: den 6 mars 2009 17:18
	To: Mats Näslund
	Cc: Jean-Marc Valin; Colin Perkins; Stefan Döhla; [email-masked]
	Subject: Re: [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt

	hi Mats 
	  Do you think it can be secured without sacrificing the extremely low data-rate properties of VBR?

	Mark

		Hi Jean-Marc,

		/Mats

			Hi Colin, Mats,

			
			Cheers,
			
			    Jean-Marc

			-------- Message d'origine--------
			De: [email-masked] de la part de Mats Näslund
			Date: ven. 06/03/2009 07:24
			À: Colin Perkins; Stefan Döhla
			Cc: [email-masked]
			Objet : Re: [AVT] Fwd: I-D Action:draft-perkins-avt-srtp-vbr-audio-00.txt
			
			Hi Colin,

			

			Best,
			
			/Mats

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 09 Mar 2009 10:54:36 -0400

Mats Näslund wrote:
> I think David's analysis in the other mail is correct and that 
> (sufficient amount of) padding + authentication can fix this.
Just a few more comments. I'll be talking about Speex because that's 
what I know best and that's the codec that's been described in the 
original paper on VBR security.

On issue to keep in mind with padding is that Speex frames (narrowband) 
can only have 8 different lengths. This means that any padding that does 
not reach the size of the next bit-rate has no effect on the information 
leak, so the padding might as well be done *exactly* to an existing 
bit-rate. Knowing that, one would be better to simply change the 
bit-rate selection algorithm instead of using padding. The packet sizes 
would end up the same, but at least the codec would actually be *using* 
the extra bits instead of those being discarded. So we've effectively 
changed the problem from one of padding to one of better choosing the 
rate in such as way as to minimize the information leak (of course, any 
non-constant rate will have non-zero leak).

    Jean-Marc

> /Mats
>
>     ------------------------------------------------------------------------
>     *From:* Mark Baugher [mailto:[email-masked]]
>     *Sent:* den 6 mars 2009 17:18
>     *To:* Mats Näslund
>     *Cc:* Jean-Marc Valin; Colin Perkins; Stefan Döhla; [email-masked]
>     *Subject:* Re: [AVT] Fwd: I-D
>>         ------------------------------------------------------------------------
>>         *From:* Jean-Marc Valin [mailto:[email-masked]]
>>         *Sent:* den 6 mars 2009 15:43
>>         *To:* Mats Näslund; Colin Perkins; Stefan Döhla
>>         *Cc:* [email-masked] <mailto:[email-masked]>
>>         *Subject:* RE : [AVT] Fwd: I-D
>>         I think all this may be a little premature, considering that
>>         only one codec was analysed: Speex. While it's flattering as
>>         the author of Speex that there is an assumption that Speex
>>         VBR is like every other codecs's VBR, that remains to be
>>         confirmed (the fundamental cause of the leak has not been
>>         explained). Regarding padding, I think it simply defeats the
>>         purpose of VBR. Speex will *by default* produce a CBR stream
>>         and that is already the recommended way of using it for VoIP
>>         -- not because of privacy, but for real-time considerations
>>         (you can't afford buffering). With that in mind, it's a bit
>>         pointless quality-wise to change Speex to VBR and then pad to
>>         a constant packet length. I'm not aware of any speech codec
>>         that does not have a CBR mode (thought there may be some I'm
>>         not aware of). The only valid use of VBR I can think of for
>>         VoIP is when aggregating traffic, in which case and
>>         information contained in the VBR would be lost in the
>>         aggregation.
>>
>>         Mats, regarding your comment about banning VBR from
>>         non-secure streams as well, I think it's a bit pointless
>>         since any person who can see the packet lengths, can almost
>>         certainly see the packet content as well.
>>
>>         Cheers,
>>
>>             Jean-Marc
>>
>>
>>         De: [email-masked] <mailto:[email-masked]> de la
>>         part de Mats Näslund
>>         Cc: [email-masked] <mailto:[email-masked]>
>>         Objet : Re: [AVT] Fwd: I-D
>>         > From: [email-masked] <mailto:[email-masked]>
>>         [mailto:[email-masked]] On
>>         > Behalf Of Colin Perkins
>>         > Cc: [email-masked] <mailto:[email-masked]> WG
>>         <mailto:[email-masked]>
>>         > >>> To: [email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked]>
>>         > >>>
>>         <mailto:[email-masked]>
>>         > > [email-masked] <mailto:[email-masked]>
>>         > [email-masked] <mailto:[email-masked]>
>>         [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>