[secdir] secdir re-review of draft-ietf-codec-guidelines-06

Tom Yu <tlyu@MIT.EDU> Tue, 29 November 2011 20:19 UTC

Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAC71F0CAE; Tue, 29 Nov 2011 12:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l26QG6AekxGj; Tue, 29 Nov 2011 12:19:29 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id F23211F0CAD; Tue, 29 Nov 2011 12:19:28 -0800 (PST)
X-AuditID: 12074424-b7ef76d0000008dc-a5-4ed53e4e7bef
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0E.57.02268.E4E35DE4; Tue, 29 Nov 2011 15:19:27 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pATKJPjE015854; Tue, 29 Nov 2011 15:19:26 -0500
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pATKJI7r018979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2011 15:19:23 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id pATKJIIp024734; Tue, 29 Nov 2011 15:19:18 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-codec-guidelines.all@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 29 Nov 2011 15:19:18 -0500
Message-ID: <ldvpqgar8ah.fsf@cathode-dark-space.mit.edu>
Lines: 15
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqretvd9XPoH25sMWrbZdYLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK2P5rhVMBTdYK94desPawHiKpYuR k0NCwETi0uGHjBC2mMSFe+vZuhi5OIQE9jFKvL28khXC2cAo8aH/IAuEc4VJYuudh1BlXYwS vTcmsoL0iwhES6z785EJxBYWsJbomvoLyObgYBOQlji6uAwkzCKgKrHi9DQWkDCvgIXEl5Ng YR4BTommJbuZQWxeAUGJkzOfgF3HLKAlcePfS6YJjHyzkKRmIUktYGRaxSibklulm5uYmVOc mqxbnJyYl5dapGuul5tZopeaUrqJERRq7C4qOxibDykdYhTgYFTi4Z0ldtVPiDWxrLgy9xCj JAeTkijvImugEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHex2ZAOd6UxMqq1KJ8mJQ0B4uSOK/N Tgc/IYH0xJLU7NTUgtQimKwMB4eSBG+jLVCjYFFqempFWmZOCUKaiYMTZDgP0PCdIDW8xQWJ ucWZ6RD5U4yKUuK8/SAJAZBERmkeXC8sFbxiFAd6RZi3AaSKB5hG4LpfAQ1mAhrcPvkKyOCS RISUVAPjxNYyhb8nVCLspvD8Zlj+UY7T908Ui99trn2uyycnHz19fWXGpGUnv7Qf2fRzmpfG neiZ2zSF56nU7uD++lZKXZ1Vuf6yl6uAavlWtlnV1b+NLyyKvq2tGpMaYOjDlO54OjrxdkNT 5z9le/7dB25yHNk9y8OXcYX3zHuuhmZJXHECk+PtFXmUWIozEg21mIuKEwE6Dfcv4AIAAA==
Subject: [secdir] secdir re-review of draft-ietf-codec-guidelines-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Nov 2011 20:19:29 -0000

The revised draft includes a reference to RFC 6366, as requested.
There is no mention of my concern that independent implementations of
a codec can have shared vulnerabilities due to the nature of the
encodings.  (I admit this probably belongs in a update to RFC 6366.)
Has the working group considered this concern, either during the
writing of RFC 6366, or as an update to RFC 6366 (which this document
might be an appropriate vehicle for)?

Editorial:

It's still not clear whether the intent of the document is to deal
only with audio codecs.  The body text implies that it does, but it
would be helpful to confirm that in the title and/or abstract.

Thanks for disambiguating "RF" (by removing the acronym).