[secdir] secdir review of draft-ietf-payload-g7110-03

<Steve.Hanna@infineon.com> Tue, 28 October 2014 01:34 UTC

Return-Path: <steve.hanna@infineon.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFBE1A802B; Mon, 27 Oct 2014 18:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7LDs26pd6t2; Mon, 27 Oct 2014 18:34:35 -0700 (PDT)
Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36321A870C; Mon, 27 Oct 2014 18:34:34 -0700 (PDT)
X-SBRS: None
Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2014 02:34:33 +0100
Received: from MUCSE608.infineon.com (mucltm01.eu.infineon.com [172.23.8.248]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Tue, 28 Oct 2014 02:34:31 +0100 (CET)
Received: from MUCSE610.infineon.com (172.23.7.111) by MUCSE608.infineon.com (172.23.7.109) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Oct 2014 02:34:30 +0100
Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE610.infineon.com (172.23.7.111) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Oct 2014 02:34:30 +0100
Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.028; Tue, 28 Oct 2014 02:34:30 +0100
From: Steve.Hanna@infineon.com
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-payload-g7110.all@tools.ietf.org
Thread-Topic: secdir review of draft-ietf-payload-g7110-03
Thread-Index: AQHP8kaSDwX/4D5c2Uah75RQ9hKEzpxEqeIA
Date: Tue, 28 Oct 2014 01:34:29 +0000
Message-ID: <fb18dcae02d245efaef7155bede528a7@MUCSE609.infineon.com>
References: <544EE3F8.90900@hannas.com>
In-Reply-To: <544EE3F8.90900@hannas.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.23.8.248]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_04C5_01CFF22D.C8CF4270"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BVegKxxQjNAh1wS8ebMBr_0YWSE
Subject: [secdir] secdir review of draft-ietf-payload-g7110-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 01:34:38 -0000

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".