Subject: [secdir] secdir review of draft-ietf-codec-guidelines-05

From: Tom Yu <[email-masked]>
Date: Wed, 19 Oct 2011 15:15:01 -0400

This document gives procedural guidance on the development of codecs
within the IETF.  In its Security Considerations section, it says:

   The procedural guidelines for codec development do not have
   security considerations.  However, the resulting codec needs to
   take appropriate security considerations into account, for example
   as outlined in [DOS] and [SECGUIDE].

I think that additionally, authors of codec specifications should
consider what implementation vulnerabilities are likely to arise, and
document them in the specification.  As I recall, audio, video, and
image codecs have a long history of implementation vulnerabilities
shared among multiple implementations.

These shared vulnerabilities could be due to the encodings being
mostly binary in nature, sometimes with explicit length counts for
arrays, inviting buffer overflows when implemented in languages such
as C.  (I have not extensively studied these vulnerabilities, but I'm
sure other people have done so in much more detail.)

Editorial:

It's not clear what kinds of codecs are being considered.  Text in the
document implies that the focus is audio codecs rather than video or
other codecs, but perhaps the document should clarify what kinds of
codecs are in scope.

I misinterpreted "RF license" as "radio-frequency license" initially,
but a few clauses earlier, I found that "RF" is used to represent
"royalty-free".  As there are no other occurrences of "RF" with this
meaning, consider writing it in expanded form in both places (possibly
leaving the "RF" parenthetical for the first occurrence).

---

From: David McGrew <[email-masked]>
Date: Wed, 19 Oct 2011 15:36:59 -0700

>   as outlined in [DOS] and [SECGUIDE].

That text implies that there are no security considerations in codec  
design, and that is not true.  One important consideration is that  
variable bit rate codecs can leak information through packet lengths;  
this is discussed in draft-ietf-avtcore-srtp-vbr-audio-03, which I  
suggest be referenced.   It is important to note that this issue is  
*not* specific to SRTP; it applies to any implementation of any  
encryption protocol in which the length of the plaintext can be  
inferred from that of the ciphertext (in other words, most  
implementations of most protocols).

There are actually a lot of security considerations in codec designs.   
VBR codecs can save bandwidth by making some packets shorter, but  
having plaintext-dependent packet lengths will introduce a side  
channel.  Packet lengths could be made more uniform using a short  
buffering strategy, but that would introduce latency.  Security is  
directly in tension with bandwidth and latency.   It is potentially  
valuable for codec designers to take this into consideration, because  
the codec design is the only place where we have a chance to resolve  
this tension.  (We can mitigate the VBR packet length side channel by  
padding out packets, but that negates most of the VBR benefits.)    
Note that the SPEEX codec that was shown to be most vulnerable in the  
[spot-me] reference in ietf-avtcore-srtp-vbr-audio-03 is particularly  
bad security-wise because it maps phonemes to codewords (and thus  
there is an association between phonemes and packet lengths).   I  
would guess that it could be re-designed to be more leak-resistant  
without losing all of its bandwidth efficiency.  (For example, if it  
had fewer codeword lengths, that would make it harder to distinguish  
outputs.  For bandwidth saving, you want to shave every byte off.  To  
prevent a side-channel though, you will sometimes want to leave in a  
padding byte so that two different codewords have the same length.)

David

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 19 Oct 2011 20:06:40 -0400

On Wed, 2011-10-19 at 15:36 -0700, David McGrew wrote:
> design

No, it certainly does not.  It implies that there are no security
considerations in _the procedural guidelines_.  This is a process
document, and having just read large parts of it, I agree with the
statement as written.

That said, I would not be opposed to seeing this section grow to include
a list of specific security considerations that codec specificiations
proposed under this process must address.

-- Jeff

---

From: David McGrew <[email-masked]>
Date: Thu, 20 Oct 2011 04:44:19 -0700

Hi Jean-Marc,

On Oct 19, 2011, at 6:08 PM, Jean-Marc Valin wrote:

> On 19/10/11 06:36 PM, David McGrew wrote:
>> Note that the
>> SPEEX codec that was shown to be most vulnerable in the [spot-me]
>> reference in ietf-avtcore-srtp-vbr-audio-03 is particularly bad
>> security-wise because it maps phonemes to codewords (and thus there  
>> is
>> an association between phonemes and packet lengths).
>
> As the author of Speex, I can assure you that it is far from being
> sufficiently advanced to "map phonemes to codewords". It only has a
> handful rates it can use at any time and chooses between those based  
> on
> (too) simple heuristics.

apologies for my simplistic characterization.

>
>> I would guess
>> that it could be re-designed to be more leak-resistant without losing
>> all of its bandwidth efficiency.  (For example, if it had fewer  
>> codeword
>> lengths, that would make it harder to distinguish outputs.  For
>> bandwidth saving, you want to shave every byte off.  To prevent a
>> side-channel though, you will sometimes want to leave in a padding  
>> byte
>> so that two different codewords have the same length.)
>
> As I said, there's only a few possible rates. There's a total of 8  
> rates
> but at most 4-5 can be used for a certain target rate. From an
> experiment I did, when one considers the correlation in rate between
> adjacent frames, the entropy contained in the rate switching is  
> about 1
> bit/frame. So if one wanted to create a covert channel based on Speex
> bit-rates, the max throughput without being detected would be ~50 b/s.
> Considering that most of the 50 b/s is noise, the actual leak is quite
> small.
>
> I think the VBR leak is really blown out of proportion and is really a
> concern only in a handful of applications,

I agree.

> as detailed in
> ietf-avtcore-srtp-vbr-audio. With that in mind, I don't really see
> anything to add in the guidelines -- especially considering that the
> issue is addressed in the actual codec requirements (see
> http://tools.ietf.org/html/rfc6366 ).

It would be good to have the security considerations point to that  
section of RFC6366.

That RFC says that codecs should have a constant bitrate mode.  ietf- 
avtcore-srtp-vbr-audio says that CBR should be used in scenarios where  
VBR is considered unsafe.   That's all good advice, but the  
implication is that VBR should be turned off when security is a goal  
(since it is unrealistic to suppose that users or applications could  
do a good job of dynamically switching between CBR/VBR to reflect  
their current situation).   Are you comfortable with this, or do you  
think that there should be guildelines that encourage the development  
and use of codecs that make an effort to minimize the leakage of  
plaintext information through packet lengths and timings?

David

> Cheers,
> 	Jean-Marc

---

From: Tom Yu <[email-masked]>
Date: Thu, 20 Oct 2011 14:07:09 -0400

Jean-Marc Valin <[email-masked]> writes:

> concern only in a handful of applications, as detailed in

I think this document should reference the Security Considerations
section of RFC 6366.  (It currently does not.)  I think RFC 6366 could
additionally emphasize that independent implementations of codecs can
have shared vulnerabilities due to things like binary encodings and
explicit length counts for arrays, but it may be too late to bother
making such an update (either in a successor to RFC 6366 or in this
document).

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 19 Oct 2011 21:08:58 -0400

On 19/10/11 06:36 PM, David McGrew wrote:
> security-wise because it maps phonemes to codewords (and thus there is

As the author of Speex, I can assure you that it is far from being
sufficiently advanced to "map phonemes to codewords". It only has a
handful rates it can use at any time and chooses between those based on
(too) simple heuristics.

> all of its bandwidth efficiency.  (For example, if it had fewer codeword
> side-channel though, you will sometimes want to leave in a padding byte

As I said, there's only a few possible rates. There's a total of 8 rates
but at most 4-5 can be used for a certain target rate. From an
experiment I did, when one considers the correlation in rate between
adjacent frames, the entropy contained in the rate switching is about 1
bit/frame. So if one wanted to create a covert channel based on Speex
bit-rates, the max throughput without being detected would be ~50 b/s.
Considering that most of the 50 b/s is noise, the actual leak is quite
small.

Cheers,

	Jean-Marc