Last Call Review of draft-ietf-payload-g7110-03
review-ietf-payload-g7110-03-secdir-lc-hanna-2014-10-30-00

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area 
directors.  Document editors and WG chairs should treat these comments just 
like any other last call comments.

This document defines an RTP payload format for ITU-T Recommendation G.711.0. 
The document also defines a storage mode format for G.711.0 and a media type 
registration for the G.711.0 RTP payload format. Although G.711.0 is a 
lossless and stateless compression algorithm, it is a real compression 
algorithm and therefore results in variable bit rate encoding.

In my view, this document is Ready with Issues. The issues that I am concerned 
about are described in the next two paragraphs.

I am a novice in media encoding and the security issues raised by it. However, 
I was surprised to see that RFC 6562 (Guidelines for the Use of Variable Bit 
Rate Audio with Secure RTP) was not mentioned in the Security Considerations 
section. The VBR security problems cited in RFC 6562 seem to apply to this 
draft and the mitigation techniques described in the draft don't seem to 
properly address those problems. For example, adding statistically variable 
padding to very small G.711.0 frames would not prevent recognition of a 
prerecorded message if the set of all possible messages is known. If the 
authors of this draft have not consulted an expert on the security issues 
raised by VBR, they should do so. At least, I would expect to see a reference 
to RFC 6562 and an explanation of why the mitigation techniques described in 
the draft are adequate or a description of the circumstances where they fall 
short.

In addition to this concern, a believe that there may be a buffer overrun 
vulnerability in the payload decoding algorithm described in section 4.2.3. 
The authors carefully ensure that the input buffer is not overrun but no 
similar protections for the output buffer are described. At least, I didn't 
see them. A buffer overrun of the output buffer would be a major flaw. If such 
a flaw is present (and I believe that it is), the document should not be 
allowed to proceed until this flaw is fixed.

Here is a list of non-substantive issues that I noticed.

On page 4, attribute A1 says:

  G.711.0 was designed
  as its primary use case for the compression of G.711 payloads
  that contained "speech" or other zero-mean acoustic signals.

The grammar there is not correct. I would suggest instead:

  In the design of G.711.0,
  the primary use case was the compression of G.711 payloads
  that contained "speech" or other zero-mean acoustic signals.

In section 4.1, you say that "one of the advantages of G.711.0 over G.711 with 
VAD is the lack of any VAD-inducing artifacts in the received signal." Do you 
really mean "VAD-inducing" or do you mean "VAD-induced"?

On page 13, step H3 should start with "If this octet is 0x00", not just "If 
this octet 0x00". Otherwise, this introductory clause is missing a verb.

On page 17, the last sentence of the description of complaw says "are used 
for". This should say "which are used for".

On page 21, the second paragraph of section 6 includes the words "that not 
received". This should be "that are not received".

In the first sentence of section 6.1, "payloads not received" should be 
"payloads are not received".



Attachment:


smime.p7s




Description:

 S/MIME cryptographic signature