From nobody Tue Aug 1 11:07:09 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C051321CD; Tue, 1 Aug 2017 11:07:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: codec@ietf.org, ietf@ietf.org, draft-ietf-codec-opus-update.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150161082225.9505.16606445945798880852@ietfa.amsl.com> Date: Tue, 01 Aug 2017 11:07:02 -0700 Archived-At: Subject: [codec] Genart last call review of draft-ietf-codec-opus-update-08 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:07:02 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-codec-opus-update-08 Reviewer: Robert Sparks Review Date: 2017-08-01 IETF LC End Date: 2017-08-09 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a Standards Track RFC This document is straightforward in the changes it is making to OPUS. My only note of sadness is that it continues to use a documentation mechanism started by RFC6716 of effectively making a normative reference to the _proceedings_ of previous IETF meetings. (Note that this document does this twice: once for the patch file, which is a convenience - the information is in the draft, and once for the updated test vectors. This is _not_ a convenience, the information is not in the draft. If, for whatever reason, the proceedings URL could not be retrieved, someone could not verify their implementation with the updated test vectors). On the one hand, we've set the precedent, and we could agree to just let this go (I'm recommending that to the IESG with this review). On the other hand, we could make things _slightly_ better (or perhaps just different) by putting the test vectors in the doc as an appendix as a uuencoded compressed tarball. From nobody Tue Aug 1 12:09:01 2017 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620971321C3 for ; Tue, 1 Aug 2017 12:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jmvalin-ca.20150623.gappssmtp.com 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 FAnY2cfMyvqV for ; Tue, 1 Aug 2017 12:08:51 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9EF1322E5 for ; Tue, 1 Aug 2017 12:08:51 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 77so12750620itj.1 for ; Tue, 01 Aug 2017 12:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jmvalin-ca.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=+lMevIy0v0cRFwHCQhGqtcKpdAqC5HP63DBgibokKDU=; b=kkh7OEnxkPMyg0glbuLiv4+hrWN/y2sPbNXZshwjcHE4/0NeWaqaPf3XQ50DHOfpzX t0su0UNs6MLwXe/nFiVTWAjPWt0G4Ti6mZWV6tQTgXcn1wROohIcWBoyRCj6LDLvqFvF HLOYThVxAp34MRhEWCwjsgtg8WQzbV6dHvt8RCTrOOsbZFxWEWB5LphkPkl/PNVumLiz /kXxWlzn5I43QDTiPHytuImg3LYwyZjugEcdd5ZJ0LVJqvCF+c3pOnbK89ByR+TtbWHQ cR88IqMT1OZseBOCqHVC7XNWO/CGTEc/IfP9q7PaAAlaipOjDrFU2a4OkflHFyz7W5uQ fIMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=+lMevIy0v0cRFwHCQhGqtcKpdAqC5HP63DBgibokKDU=; b=obHn0LRYNw61dnmxKzzvh1rUNTymO9PsI0YWUY/o376ZPhjHZe7juPu2un7X4pm9TA Kc00vIFwuG46G4nV+aaPvaLBg0TzA1cleCNKyzh1+QWui5fBXbuzTzI06D5Ds6GsrS9y s7Z6wxMp90tBk57n2iab+9Aa91JZpYKWhuunVTa1DFsYm8l9s3UZeZfpHkV3GaK8Yt+I N/WWCTgQs89R5okUS/zv9s/DwyPjjHSQizHnGe5E4m/1GXan1n74ttQOdcFpbup1+cVH 1E+EO9DP40GWdZ34bU+eBlqj5HIEZydH2l47XwUhgFFsPjjTgskED2aU396d429c/oDl riow== X-Gm-Message-State: AIVw112xnm+bwWYxaml/J9U0LLTimbHwBplFuqF3tpGaVDKoEVY5TVsg +0MqYD54KTJY9vhmSog= X-Received: by 10.36.53.141 with SMTP id k135mr2782969ita.176.1501614530546; Tue, 01 Aug 2017 12:08:50 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id s204sm1044357itb.13.2017.08.01.12.08.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 12:08:49 -0700 (PDT) To: Robert Sparks , gen-art@ietf.org References: <150161082225.9505.16606445945798880852@ietfa.amsl.com> Cc: codec@ietf.org, ietf@ietf.org, draft-ietf-codec-opus-update.all@ietf.org From: Jean-Marc Valin Message-ID: <7a13a147-5be7-f15b-2d93-88b0922ef543@jmvalin.ca> Date: Tue, 1 Aug 2017 15:08:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <150161082225.9505.16606445945798880852@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [codec] Genart last call review of draft-ietf-codec-opus-update-08 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 19:08:53 -0000 Hi Robert, Thanks for the review. The main issue with including uuencoded testvectors in the document is that it would cause the RFC to be around 32000 pages long. That's why RFC6716 included the source code, but not the test vectors. Back then, we were told that the meeting material was the only place we could put the test vectors. I don't really like doing that, but it still beats the other options I'm aware of (unless I missed something). Cheers, Jean-Marc On 01/08/17 02:07 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-codec-opus-update-08 > Reviewer: Robert Sparks > Review Date: 2017-08-01 > IETF LC End Date: 2017-08-09 > IESG Telechat date: Not scheduled for a telechat > > Summary: Ready for publication as a Standards Track RFC > > This document is straightforward in the changes it is making to OPUS. > > My only note of sadness is that it continues to use a documentation mechanism > started by RFC6716 of effectively making a normative reference to the > _proceedings_ of previous IETF meetings. (Note that this document does this > twice: once for the patch file, which is a convenience - the information is in > the draft, and once for the updated test vectors. This is _not_ a convenience, > the information is not in the draft. If, for whatever reason, the proceedings > URL could not be retrieved, someone could not verify their implementation with > the updated test vectors). > > On the one hand, we've set the precedent, and we could agree to just let this > go (I'm recommending that to the IESG with this review). On the other hand, we > could make things _slightly_ better (or perhaps just different) by putting the > test vectors in the doc as an appendix as a uuencoded compressed tarball. > From nobody Mon Aug 14 08:56:36 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F3B1323A0; Mon, 14 Aug 2017 08:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-codec-opus-update@ietf.org, Tim Terriberry , codec-chairs@ietf.org, tterriberry@mozilla.com, codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150272618954.396.2989336786082869936.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 08:56:29 -0700 Archived-At: Subject: [codec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-codec-opus-update-08=3A_=28with_COMMENT=29?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 15:56:30 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-codec-opus-update-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I support the publication as this seems to be the right thing for me to do in this situation, I find it really weird that we have to publish an RFC to fix bugs in an example implementation in the appendix (that is even encoded). While it is a good thing to have code in an RFC as far as this helps implementation, maybe rfc6716 went to far with putting a whole reference implementation in there. I guess that has also led to a situation where everybody is just using the provided code while efforts to reimplement the spec could have detected these bugs earlier in the process. Maybe it's an item for the IESG to thinking about how to provide a reference implementation with an RFC (that maybe can be updated easier) other than just putting it in the appendix. One more actionable comment: I think the abstract could say more about the updates, especially maybe noticing that this only updates the code in the appendix and not the normative language in the body. From nobody Mon Aug 14 12:30:35 2017 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593713240E; Mon, 14 Aug 2017 12:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 8BNuUgTbuUWB; Mon, 14 Aug 2017 12:30:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632A8132408; Mon, 14 Aug 2017 12:30:28 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v7EJUQIo015149 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Aug 2017 14:30:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <150272618954.396.2989336786082869936.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 14:30:27 -0500 Cc: The IESG , tterriberry@mozilla.com, codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-opus-update@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150272618954.396.2989336786082869936.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [codec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-codec-opus-update-08=3A_=28with_COMMENT=29?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:30:33 -0000 > On Aug 14, 2017, at 10:56 AM, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-codec-opus-update-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > While I support the publication as this seems to be the right thing = for me to > do in this situation, I find it really weird that we have to publish = an RFC to > fix bugs in an example implementation in the appendix (that is even = encoded). > While it is a good thing to have code in an RFC as far as this helps > implementation, maybe rfc6716 went to far with putting a whole = reference > implementation in there. I guess that has also led to a situation = where > everybody is just using the provided code while efforts to reimplement = the spec > could have detected these bugs earlier in the process. Maybe it's an = item for > the IESG to thinking about how to provide a reference implementation = with an > RFC (that maybe can be updated easier) other than just putting it in = the > appendix The reference implementation in the appendix in RFC 6716 is not just an = example implementation. It contains the normative specification of the = bit stream decoder=E2=80=94which makes up the majority of the normative = bits in that document.=20 That has, so far, been a very uncommon approach, and I don=E2=80=99t = know that we would do it again. But if we choose to do so, I absolutely = agree we should consider whether it can be done in an easier to update = fashion.=20 Ben. >=20 > One more actionable comment: I think the abstract could say more about = the > updates, especially maybe noticing that this only updates the code in = the > appendix and not the normative language in the body. >=20 >=20 From nobody Tue Aug 15 09:40:53 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 378E812426E; Tue, 15 Aug 2017 09:40:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-codec-opus-update@ietf.org, Tim Terriberry , codec-chairs@ietf.org, tterriberry@mozilla.com, codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 09:40:46 -0700 Archived-At: Subject: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:40:46 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-codec-opus-update-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for producing this specification. I have some questions, but nothing at Discuss level. I have no idea what an “extreme bitstream” is. Aren’t they all pretty much 0s and 1s? More seriously, it would be nice to know what about the bitstream is extreme. Googling for ‘opus “extreme bitstream”’ turns up one hit for side effects from a drug being tested, so that wasn’t much help. Is there an obvious way that the decoder can know whether audio will be downmixed outside the decoder? Section 10 thinks decoders can know that, apparently. In the security considerations, why is it highly unlikely that the read-only table will be placed next to sensitive data? I’m not balloting Discuss on this because the assertion is nested in a reported vulnerability with no known exploit, but I am curious. From nobody Tue Aug 15 10:23:05 2017 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74904132395 for ; Tue, 15 Aug 2017 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com 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 QvSUtuQS2XMS for ; Tue, 15 Aug 2017 10:22:59 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FB013219E for ; Tue, 15 Aug 2017 10:22:59 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 76so7350108ith.0 for ; Tue, 15 Aug 2017 10:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=MpvWks/BhqetursiDfEHqR7eO5ndzZJGPKyAdTKFYeI=; b=D+Qi8yXmkRPvxNjXHPsrYml374r3KYWaEwhdcoHp83bCsGFAsPOe8CV0zW6sXm7qI8 OSJWdZ31ylwZhTA3f06uQb57pDZ+8quAWsveaKPLDPrZVkPCUpwXpxHjz40vQuQpZu3/ orqE7d+P23qym1z8RcU2TCXNdC19PKbaxgo/U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=MpvWks/BhqetursiDfEHqR7eO5ndzZJGPKyAdTKFYeI=; b=sz6Z1enmvzLuCaDjwP1CcAVWLLUAmEqYVeyX/BHt8VxdwRGDqXQZCD9Odo5abVlJoZ c9vuTfPPragenNda+rO2uQD0uSN92Nbpi7wkqsMw9Z7QD3qFWVqJsStJIUKNqklsaypY nxkDnBMazQ7T4Xsjcl1ilUc53yrlt9DVnb9jxavoO4zFP9Wjq3jo9j5dHDAHXgK6+Naz E28ekQMo8SpSbeLipEG4Dpi9FoSN+ZePTYISonpY0b2p1jYUk9O4skoi99rYtTjWmKJz cFeW7jWV+1xKRvb/keorYzUCLod0nQLILqmj92hmFDgQUmMz7bXiZAPOmOyy4z/uxJ1c TuAQ== X-Gm-Message-State: AHYfb5gddx4rDc0q5geU1wcLBxr/A+CgPvNdlZ16deCsJ025ErLW6J6N S+sE0IJTYbzsD59L X-Received: by 10.36.69.13 with SMTP id y13mr1725834ita.100.1502817778671; Tue, 15 Aug 2017 10:22:58 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable067.31-56-74.mc.videotron.ca. [74.56.31.67]) by smtp.gmail.com with ESMTPSA id s44sm1017241ite.30.2017.08.15.10.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 10:22:57 -0700 (PDT) To: Spencer Dawkins , The IESG References: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> Cc: tterriberry@mozilla.com, codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-opus-update@ietf.org From: Jean-Marc Valin Message-ID: Date: Tue, 15 Aug 2017 13:22:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bSQAbCxEKTaNn4hW0Wggdkvm4efh8iqAP" Archived-At: Subject: Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:23:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bSQAbCxEKTaNn4hW0Wggdkvm4efh8iqAP Content-Type: multipart/mixed; boundary="TfVt3sNACFg45xEOKNGbpwRh0sSATRhOX"; protected-headers="v1" From: Jean-Marc Valin To: Spencer Dawkins , The IESG Cc: tterriberry@mozilla.com, codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-opus-update@ietf.org Message-ID: Subject: Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) References: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> In-Reply-To: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> --TfVt3sNACFg45xEOKNGbpwRh0sSATRhOX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Spencer, Thanks for the comments. See below. On 15/08/17 12:40 PM, Spencer Dawkins wrote: > I have no idea what an =E2=80=9Cextreme bitstream=E2=80=9D is. Aren=E2=80= =99t they all pretty much 0s > and 1s? >=20 > More seriously, it would be nice to know what about the bitstream is ex= treme. What is meant here is that the bit-stream is trying to represent an extremely large value for the high LSF parameters. It's either impossible or at least extremely unlikely for an encoder to generate such a bit-stream that triggers the bug. So any occurrence would likely be specially crafted rather than random. Would you prefer the word "malicious" instead of "extreme" here? > Is there an obvious way that the decoder can know whether audio will be= > downmixed outside the decoder? Section 10 thinks decoders can know that= , > apparently. The most common case is when the application initializes a mono decoder (e.g. the receiver has just one speaker), but is decoding a stereo file (or the sender is sending a stereo stream). In that case, the down-mixing occurs in the decoder itself. In the other case, the application developer would have to explicitly tell the decoder that its stereo output is meant to be down-mixed. > In the security considerations, why is it highly unlikely that the read= -only > table will be placed next to sensitive data? I=E2=80=99m not balloting = Discuss on this > because the assertion is nested in a reported vulnerability with no kno= wn > exploit, but I am curious. Well, the linker will typically have a text segment where it puts all the executable code and the read-only data, separate from the heap and other writable areas. The out-of-bounds read is just 256 bytes before the target table and the text segment would typically be around 200 kB. So the only way for the out-of-bounds read to be outside of the text segment (which isn't sensitive because everyone can have it) is if the linker placed the table in the first 0.1% of the read-only segment. That being said, in response to the SecDir review, I proposed rewriting that part to say: "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit out-of-bounds read to a fixed location 256 bytes before a constant table. That location would normally be part of an executable's read-only data segment, but if that is not the case, the bug could at worst results in either a crash or the leakage of 16 bits of information from that fixed memory location (if the attacker has access to the decoded output). Despite the claims of the CVE, the bug cannot results in arbitrary code execution." Would that address your concerns? Cheers, Jean-Marc --TfVt3sNACFg45xEOKNGbpwRh0sSATRhOX-- --bSQAbCxEKTaNn4hW0Wggdkvm4efh8iqAP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZky3wAAoJEF5d2aNvkYnIn0AP/2H1vvhBYmP38n5Lvk5jc1Aj 62QFrV9aguITbIxApXqo+Uxr5D6ePlS4UNzHWOt+iMBRngwW5z6X+0f4GHxWWTo9 mrtB5u69lBPXcuG8RqJPx5PvKhCbbW87OYm/Vxk9oR+pf99K+OK1GZvj0bs+BRvi Aw+TVH0g9dPug8/XMQqwcLbphbjVI2fTMKZkuYxvow7pvwJ4e/qjCJA1StVFiOx7 o5Dxt31zTErS5Ukrkt0wCKWdGgzqY9MQ6L6t/6ah+YlBkrxgDNDdMmPV7zGUoepW wA8XMfYRqn1q2MykX0xTqz0iurS9fSeyA4uac/rrDPiujtW2tGnVv5F7qGJBcuir 9jFlUPzALeucGI50OZoeKvqA/XkgvJ8XdOiS46v0Hidsxo8U/IkQ2FSuK1ptpj4a 60F2gGhRJ4ib3mlZhPVcYTAZLdhZld99mpvNzYg3ZzBObPAwvRfmUm3xh2GXbHNR byUWnrxVL5rdFC3N3pO5Esj7HhqlBHBtBPvk48tDSTHIBmklG4vBOBzlci1maJU+ WgRoTAQ1TpUfqcihyl4b/LdpAaBOxQSAEFgXyVj26e49mcpgLJDZbw/aR3CTy8hl utqCC+hn5kyu5gwoq2ntB+J38W7qgDeGKhKMMAXGYT7jfDJquodJgxw7gLn9It4o fZynt7lVqkspVjprk3SU =Qfcw -----END PGP SIGNATURE----- --bSQAbCxEKTaNn4hW0Wggdkvm4efh8iqAP-- From nobody Tue Aug 15 11:23:00 2017 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05422132398; Tue, 15 Aug 2017 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G_IkqFMbAgDR; Tue, 15 Aug 2017 11:22:50 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBF513226B; Tue, 15 Aug 2017 11:22:50 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id u207so9524673ywc.3; Tue, 15 Aug 2017 11:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vwxmhQZ2uDpvyCh0LPk1GfAQJngAfFh2F+RpMHEErPQ=; b=lzwAXQI48N7kJDFBUdzkcfSx/2ethYA7JT8dV0uhtIhsKzAxpB1UgUgPgQbxFD8lVO +/gbUz2GXQgS5Mw0YMqJzEqUpR61u19OaeBrHRQh0zRwR4Ph2WVz1BJC/NGnMFnFSRrw nQqhO/TMtVT/FNLy10sInPxgHwGMc5ddThRNBDLuC3kku47XW3dqEiN+nCL7U+2TXRRo evazBBuJUJg1tnjiJW6rCQUA3lxTmOOQc2WqNWrgzueQZtvyMIfpnR70dpirZ2MMeaQO zE8WmeZ6puEt0E80dVdh95+g7NqxfnKJhtwvGtxNAl2QKjhMiTMY89ul+1Jh+QTOCTvH 7pcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vwxmhQZ2uDpvyCh0LPk1GfAQJngAfFh2F+RpMHEErPQ=; b=PsPs6iNbVJEg1qkbgn+acFugI2rPqaCrFAjsYNpSV5zrJJpv7u9WPaHA3hdYmckqek ThXMRUlJ3iEmTDdjpI51KEIezJPCBvIP589E3FQn/yduvNyWgF3B8qi9+yv7LFzkIO8U 7KJhAdXj6A30GTwnzgYSfbXT8x8MC01aOWrfjVCOtEnyAqIlJfVxFhzGNzD13S3gC1ot a3Z3Lr85e6XFfBf6QBOt18JqigeImMn9oYAFKJC5UYpRpJH1oIN0KcyNfyHLBOf+hQcS 17pgSfAH9BPDD0W01MPf5/H7+ksVHSVxF3P+G7fA2ZJsCBeyvhBP1Hp4eS0X2TsFdpHl e7Cg== X-Gm-Message-State: AHYfb5jYF7DfFcGYN9n6Vkjnbs+ZPY7BOeM2bF5IhNK+iyT0e+m8y02a 0/1PGeJPh5B0mkD8fo6abAMYl97amQ== X-Received: by 10.37.189.141 with SMTP id f13mr9656855ybh.39.1502821369458; Tue, 15 Aug 2017 11:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.79 with HTTP; Tue, 15 Aug 2017 11:22:48 -0700 (PDT) In-Reply-To: References: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 15 Aug 2017 13:22:48 -0500 Message-ID: To: Jean-Marc Valin Cc: The IESG , tterriberry@mozilla.com, codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-opus-update@ietf.org Content-Type: multipart/alternative; boundary="089e0822d2e4e338090556ceddb1" Archived-At: Subject: Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 18:22:53 -0000 --089e0822d2e4e338090556ceddb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jean-Marc, On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin wrote: > Hi Spencer, > > Thanks for the comments. See below. > By the way, ADs always appreciate responses when they can still remember what they were thinking when they balloted. You rock! > > On 15/08/17 12:40 PM, Spencer Dawkins wrote: > > I have no idea what an =E2=80=9Cextreme bitstream=E2=80=9D is. Aren=E2= =80=99t they all pretty > much 0s > > and 1s? > > > > More seriously, it would be nice to know what about the bitstream is > extreme. > > What is meant here is that the bit-stream is trying to represent an > extremely large value for the high LSF parameters. It's either > impossible or at least extremely unlikely for an encoder to generate > such a bit-stream that triggers the bug. So any occurrence would likely > be specially crafted rather than random. Would you prefer the word > "malicious" instead of "extreme" here? > So to tease this apart - my comment was hoping for something like "a bitstream that represents an extremely large value for the high LSF parameters", which makes things clear for me. On "malicious" - you might say that such a bitstream is most likely to be hand-crafted as an exploit", or something like that, because that seems like a really good thing to say. > > Is there an obvious way that the decoder can know whether audio will be > > downmixed outside the decoder? Section 10 thinks decoders can know that= , > > apparently. > > The most common case is when the application initializes a mono decoder > (e.g. the receiver has just one speaker), but is decoding a stereo file > (or the sender is sending a stereo stream). In that case, the > down-mixing occurs in the decoder itself. In the other case, the > application developer would have to explicitly tell the decoder that its > stereo output is meant to be down-mixed. > This would be much clearer if you added a sentence that captures what you just told me, unless this is in the OPUS base specification someplace. If it's not, it seems useful. (I think you're actually adding information that both codec implementers and application implementers need to know - decoders that can downmix need to have an input for an application to tell them not to downmix. If I understand correctly, that would also be good to write down someplace) > > In the security considerations, why is it highly unlikely that the > read-only > > table will be placed next to sensitive data? I=E2=80=99m not balloting = Discuss > on this > > because the assertion is nested in a reported vulnerability with no kno= wn > > exploit, but I am curious. > > Well, the linker will typically have a text segment where it puts all > the executable code and the read-only data, separate from the heap and > other writable areas. The out-of-bounds read is just 256 bytes before > the target table and the text segment would typically be around 200 kB. > So the only way for the out-of-bounds read to be outside of the text > segment (which isn't sensitive because everyone can have it) is if the > linker placed the table in the first 0.1% of the read-only segment. > > That being said, in response to the SecDir review, I proposed rewriting > that part to say: > > "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit > out-of-bounds read to a fixed location 256 bytes before a constant > table. That location would normally be part of an executable's read-only > data segment, but if that is not the case, the bug could at worst > results in either a crash or the leakage of 16 bits of information from > that fixed memory location (if the attacker has access to the decoded > output). Despite the claims of the CVE, the bug cannot results in > arbitrary code execution." > > Would that address your concerns? > Yes, because it moves from "think happy thoughts and everything will be fine" to providing enough information for implementers to assess risk, and because someone who understands security better than I do is also working with you on this text! Thanks for all this. Spencer > Cheers, > > Jean-Marc > > --089e0822d2e4e338090556ceddb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jean-Marc,

On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin <jmvalin@moz= illa.com> wrote:
Hi Spenc= er,

Thanks for the comments. See below.

By = the way, ADs always appreciate responses when they can still remember what = they were thinking when they balloted. You rock!
=C2=A0

On 15/08/17 12:40 PM, Spencer Dawkins wrote:
> I have no idea what an =E2=80=9Cextreme bitstream=E2=80=9D is. Aren=E2= =80=99t they all pretty much 0s
> and 1s?
>
> More seriously, it would be nice to know what about the bitstream is e= xtreme.

What is meant here is that the bit-stream is trying to represent an<= br> extremely large value for the high LSF parameters. It's either
impossible or at least extremely unlikely for an encoder to generate
such a bit-stream that triggers the bug. So any occurrence would likely
be specially crafted rather than random. Would you prefer the word
"malicious" instead of "extreme" here?
=

So to tease this apart - my comment was hoping for some= thing like "a bitstream that represents an extremely large value for t= he high LSF parameters", which makes things clear for me.
On "malicious" - you might say that such a bitstream= is most likely to be hand-crafted as an exploit", or something like t= hat, because that seems like a really good thing to say.
=C2=A0
> Is there an obviou= s way that the decoder can know whether audio will be
> downmixed outside the decoder? Section 10 thinks decoders can know tha= t,
> apparently.

The most common case is when the application initializes a mono deco= der
(e.g. the receiver has just one speaker), but is decoding a stereo file
(or the sender is sending a stereo stream). In that case, the
down-mixing occurs in the decoder itself. In the other case, the
application developer would have to explicitly tell the decoder that its stereo output is meant to be down-mixed.

This would be much clearer if you added a sentence that captures what you= just told me, unless this is in the OPUS base specification someplace. If = it's not, it seems useful.=C2=A0

(I think you&= #39;re actually adding information that both codec implementers and applica= tion implementers need to know - decoders that can downmix need to have an = input for an application to tell them not to downmix. If I understand corre= ctly, that would also be good to write down someplace)
=C2=A0
> In the security cons= iderations, why is it highly unlikely that the read-only
> table will be placed next to sensitive data? I=E2=80=99m not balloting= Discuss on this
> because the assertion is nested in a reported vulnerability with no kn= own
> exploit, but I am curious.

Well, the linker will typically have a text segment where it puts al= l
the executable code and the read-only data, separate from the heap and
other writable areas. The out-of-bounds read is just 256 bytes before
the target table and the text segment would typically be around 200 kB.
So the only way for the out-of-bounds read to be outside of the text
segment (which isn't sensitive because everyone can have it) is if the<= br> linker placed the table in the first 0.1% of the read-only segment.

That being said, in response to the SecDir review, I proposed rewriting
that part to say:

"CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit out-of-bounds read to a fixed location 256 bytes before a constant
table. That location would normally be part of an executable's read-onl= y
data segment, but if that is not the case, the bug could at worst
results in either a crash or the leakage of 16 bits of information from
that fixed memory location (if the attacker has access to the decoded
output). Despite the claims of the CVE, the bug cannot results in
arbitrary code execution."

Would that address your concerns?

Yes, = because it moves from "think happy thoughts and everything will be fin= e" to providing enough information for implementers to assess risk, an= d because someone who understands security better than I do is also working= with you on this text!

Thanks for all this.
=

Spencer
=C2=A0
Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc


--089e0822d2e4e338090556ceddb1-- From nobody Tue Aug 15 14:31:01 2017 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DEF132428 for ; Tue, 15 Aug 2017 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 unO0oymR9AzO for ; Tue, 15 Aug 2017 14:30:57 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387C2132653 for ; Tue, 15 Aug 2017 14:30:54 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so17389348wma.0 for ; Tue, 15 Aug 2017 14:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7FG0I+9uhIAeInABv2dtHLpipatS4aMyX6422zJgyDw=; b=Arb08HowQUFANnT2w9HKdM9G7QBpN4rPQ6SCjoA61o40H2P4Fi5cw2aawc6WdDl6Fi nhgbh2OZxpO9Atba/+Cp9agrRO1cEqfgYFmOwyCLgrNdH1dMZW4b7leOtUNcfV4v5n/6 iTvg8oGOA/0B89vj1R1y4VSxmmvDJ7NSayCDEegY+NRomMJczNz4ksjTWtb48TO7T3G7 0dZXLZL8vAKH/HQVCzg+oamPNZQ0kYQDSs48ElKuGZgSWQKgAHrIuUS02XQAIBM9kDl9 UFaonXS3k1zGz+Dci/HBv55fY/doJ2WrcX3TnhtwZkCOPXgMHEuFGJV8Kl7gDiSw2ACH arWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7FG0I+9uhIAeInABv2dtHLpipatS4aMyX6422zJgyDw=; b=R3lmIhS4FhxGJsV9syPzd9RqUsONKcwZfT0YVnZpnvqJpuslBm+BQDAHloFyvDRuNi gULNOFA4WT3cfXYx5BXOaRf53moGHYpqytcwx/VJIfCGcqjO0OtXTUj0tCPWplOVn4XG v/PbHyg7nw8hLQDFNORBqgurEtdcaI8d0sHZxMWv29OGzHtX4xObfKWIZp9pGzHB1NkO FVqUzuwYHEmu5Rn1goZ8ytKsY1TTZaXsrk1xAQ9LGl+J+8aSw34pnwI769n2P3EyBSCh DYYaDJmJf42a8F1MfjQHuizxWvQ/5caS4u/590L0cbfDIZXlByv53cOvn/j5ZaKM8wkq p21g== X-Gm-Message-State: AHYfb5jhiY3do2iGJlgokZUENKDtYN2HBWfLri3vVRI4Nv+rwwANrTkm GR0XTmppTCFZRfrxyKvmi5wLFQgpsrHM X-Received: by 10.28.12.201 with SMTP id 192mr1956298wmm.45.1502832652576; Tue, 15 Aug 2017 14:30:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 15 Aug 2017 14:30:11 -0700 (PDT) In-Reply-To: References: <150281524621.21110.4158788012236698670.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Tue, 15 Aug 2017 17:30:11 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: Jean-Marc Valin , tterriberry@mozilla.com, codec-chairs@ietf.org, codec@ietf.org, The IESG , draft-ietf-codec-opus-update@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 21:30:59 -0000 On Tue, Aug 15, 2017 at 2:22 PM, Spencer Dawkins at IETF wrote: > Jean-Marc, > > On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin > wrote: >> >> Hi Spencer, >> >> Thanks for the comments. See below. > > > By the way, ADs always appreciate responses when they can still remember > what they were thinking when they balloted. You rock! > >> >> >> On 15/08/17 12:40 PM, Spencer Dawkins wrote: >> > I have no idea what an =E2=80=9Cextreme bitstream=E2=80=9D is. Aren=E2= =80=99t they all pretty >> > much 0s >> > and 1s? >> > >> > More seriously, it would be nice to know what about the bitstream is >> > extreme. >> >> What is meant here is that the bit-stream is trying to represent an >> extremely large value for the high LSF parameters. It's either >> impossible or at least extremely unlikely for an encoder to generate >> such a bit-stream that triggers the bug. So any occurrence would likely >> be specially crafted rather than random. Would you prefer the word >> "malicious" instead of "extreme" here? > > > So to tease this apart - my comment was hoping for something like "a > bitstream that represents an extremely large value for the high LSF > parameters", which makes things clear for me. > > On "malicious" - you might say that such a bitstream is most likely to be > hand-crafted as an exploit", or something like that, because that seems l= ike > a really good thing to say. > This feel like Me too, but, well, I also think that having some more explanation here would be helpful Unless you are trying not to make it too obvious that there is a security issue here (which seems like a really bad idea!) I think that explaining what the issue and why it is important would be good. This may be blindingly obvious to those schooled in art, but I certainly didn't get "extreme bitstream" means "likely malicious" (I do happen to like the term though :-) W >> >> > Is there an obvious way that the decoder can know whether audio will b= e >> > downmixed outside the decoder? Section 10 thinks decoders can know tha= t, >> > apparently. >> >> The most common case is when the application initializes a mono decoder >> (e.g. the receiver has just one speaker), but is decoding a stereo file >> (or the sender is sending a stereo stream). In that case, the >> down-mixing occurs in the decoder itself. In the other case, the >> application developer would have to explicitly tell the decoder that its >> stereo output is meant to be down-mixed. > > > This would be much clearer if you added a sentence that captures what you > just told me, unless this is in the OPUS base specification someplace. If > it's not, it seems useful. > > (I think you're actually adding information that both codec implementers = and > application implementers need to know - decoders that can downmix need to > have an input for an application to tell them not to downmix. If I > understand correctly, that would also be good to write down someplace) > >> >> > In the security considerations, why is it highly unlikely that the >> > read-only >> > table will be placed next to sensitive data? I=E2=80=99m not balloting= Discuss >> > on this >> > because the assertion is nested in a reported vulnerability with no >> > known >> > exploit, but I am curious. >> >> Well, the linker will typically have a text segment where it puts all >> the executable code and the read-only data, separate from the heap and >> other writable areas. The out-of-bounds read is just 256 bytes before >> the target table and the text segment would typically be around 200 kB. >> So the only way for the out-of-bounds read to be outside of the text >> segment (which isn't sensitive because everyone can have it) is if the >> linker placed the table in the first 0.1% of the read-only segment. >> >> That being said, in response to the SecDir review, I proposed rewriting >> that part to say: >> >> "CVE-2017-0381 is fixed by Section 7 and can only result in a 16-bit >> out-of-bounds read to a fixed location 256 bytes before a constant >> table. That location would normally be part of an executable's read-only >> data segment, but if that is not the case, the bug could at worst >> results in either a crash or the leakage of 16 bits of information from >> that fixed memory location (if the attacker has access to the decoded >> output). Despite the claims of the CVE, the bug cannot results in >> arbitrary code execution." >> >> Would that address your concerns? > > > Yes, because it moves from "think happy thoughts and everything will be > fine" to providing enough information for implementers to assess risk, an= d > because someone who understands security better than I do is also working > with you on this text! > > Thanks for all this. > > Spencer > >> >> Cheers, >> >> Jean-Marc >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Aug 15 20:02:52 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 185D3132483; Tue, 15 Aug 2017 20:02:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-codec-opus-update@ietf.org, Tim Terriberry , codec-chairs@ietf.org, tterriberry@mozilla.com, codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150285257009.12581.17244089528036604281.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 20:02:50 -0700 Archived-At: Subject: [codec] Eric Rescorla's No Objection on draft-ietf-codec-opus-update-08: (with COMMENT) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 03:02:50 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-codec-opus-update-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Document: draft-ietf-codec-opus-update-08.txt These patches are kind of hard to understand and evaluate without context. For instance, consider the following fragment /* Padding flag is bit 6 */ if (ch&0x40) { - int padding=0; int p; do { if (len<=0) return OPUS_INVALID_PACKET; p = *data++; len--; - padding += p==255 ? 254: p; + len -= p==255 ? 254: p; } while (p==255); - len -= padding; } Without knowing the type of len, it is not possible to determine whether this code is correct. For instance, say len is uint32_t, then the decrement of len may wrap. In S 5, why did you change one of these memcpys to a memmove, but not the other. S 6. LPC_inverse_pred_gain_QA(), causing a wrap-around. Although the error is harmless in practice, the C standard considers the behavior as undefined, so the following patch to line 87 of silk/ LPC_inv_pred_gain.c detects values that do not fit in a 32-bit integer and considers the corresponding filters unstable: Claiming that this is harmless in practice seems over-strong, given that undefined behavior can do anything. Even if it's harmless in practice today, it might not be in some other future compiler. S 11. In addition, any Opus implementation that passes the original test vectors from RFC 6716 [RFC6716] is still compliant with the Opus specification. However, newer implementations SHOULD be based on the new test vectors rather than the old ones. I'm not sure I understand what compliance means in this case. Are you saying that *either* behavior is compliant? Additionally, WRT the discussion on list, I don't think it's useful to go into a lot of detail about why you don't think this stuff is exploitable. It takes a huge amount of effort to validate those kinds of claims (and such claims have been wrong in other code bases in the past). I would just say what the best known attack is and leave it at that. From nobody Thu Aug 17 11:54:03 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 246D013261A; Thu, 17 Aug 2017 11:54:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150299604110.12424.3494500168119575253@ietfa.amsl.com> Date: Thu, 17 Aug 2017 11:54:01 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-opus-update-09.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 18:54:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec WG of the IETF. Title : Updates to the Opus Audio Codec Authors : Jean-Marc Valin Koen Vos Filename : draft-ietf-codec-opus-update-09.txt Pages : 12 Date : 2017-08-17 Abstract: This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the nornative decoder implementation included in the appendix of RFC 6716. The changes fixes real and potential security-related issues, as well minor quality-related issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-codec-opus-update-09 https://datatracker.ietf.org/doc/html/draft-ietf-codec-opus-update-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-opus-update-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 24 08:59:52 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C141320BD; Thu, 24 Aug 2017 08:59:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: codec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150359038455.24460.7003979214232590674@ietfa.amsl.com> Date: Thu, 24 Aug 2017 08:59:44 -0700 Archived-At: Subject: [codec] I-D Action: draft-ietf-codec-opus-update-10.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:59:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Wideband Audio Codec WG of the IETF. Title : Updates to the Opus Audio Codec Authors : Jean-Marc Valin Koen Vos Filename : draft-ietf-codec-opus-update-10.txt Pages : 11 Date : 2017-08-24 Abstract: This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in the appendix of RFC 6716. The changes fixes real and potential security-related issues, as well minor quality-related issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-codec-opus-update-10 https://datatracker.ietf.org/doc/html/draft-ietf-codec-opus-update-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-codec-opus-update-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 28 08:03:55 2017 Return-Path: X-Original-To: codec@ietf.org Delivered-To: codec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2E1132C4C; Mon, 28 Aug 2017 08:03:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, The IESG , codec@ietf.org, tterriberry@mozilla.com, Tim Terriberry , codec-chairs@ietf.org, draft-ietf-codec-opus-update@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150393262749.9924.17022339045968712707.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 08:03:47 -0700 Archived-At: Subject: [codec] Protocol Action: 'Updates to the Opus Audio Codec' to Proposed Standard (draft-ietf-codec-opus-update-10.txt) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 15:03:48 -0000 The IESG has approved the following document: - 'Updates to the Opus Audio Codec' (draft-ietf-codec-opus-update-10.txt) as Proposed Standard This document is the product of the Internet Wideband Audio Codec Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/ Technical Summary This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. That RFC normatively specifies the Opus decode in the form of C code attached as appendix A. The updates in this draft are primarily done as a series of small patches to that code. Working Group Summary Jonathan Rosenberg, then WG chair, originally stated that updates to RFC 6716 would be handled via the normal errata process. However, after conferring with our ADs, he and the chairs decided that handling these via a new draft would avoid any questions about overriding WG consensus. That decision was announced by the chairs in 2013 with the first version of the draft. Jonathan Rosenberg voiced his approval of it on the list afterwards, and no one has raised an issue with it since then. The WG held the document open for some time to give people a chance to find new issues, but the rate of new reports has dropped off, and the last issue was reported in October. Thus there is likely not much value in further postponing publication. Document Quality The updates have been implemented in libopus 1.2, released on 20 June 2017. They were available in pre-release versions for testing purposes for nearly a year prior (several years, for some of the changes). Currently they require a special option to enable them at configuration time. The authors expect to remove that option (enabling the updates by default) in a new version of libopus once this document is published as an RFC. Most users of libopus, which includes all of the major browsers, Android, iOS, and many others, will then get the new behavior once they upgrade. The authors of the Opus decoder in FFmpeg, another open source implementation, have also stated their intention to implement the updates in this draft. Mark Harris, Tina le Grand, and Jonathan Lennox all performed detailed reviews. Mark Harris is a long time contributor to the libopus open source project, with a deep familiarity with the codebase and a long track record of finding bugs and issues with new changes to it. Tina le Grand is the primary developer responsible for Opus's integration into WebRTC for Chrome, and Jonathan Lennox is the primary developer responsible for Opus's integration into Vidyo's products. Both have a number of contributions to the open source project and are familiar with the design and implementation of Opus. All three had a number of editorial suggestions, but identified no major issues with any of the proposed fixes. Additional review was performed by Ralph Giles, Michael Graczyk, Ron Lee, Felicia Lim, Gregory Maxwell, and Jan Skoglund. Personnel Document Shepherd: Timothy B. Terriberry Responsible Area Director: Ben Campbell