Re: [codec] Spencer Dawkins' No Objection on draft-ietf-codec-opus-update-08: (with COMMENT)

Spencer Dawkins at IETF <> Tue, 15 August 2017 18:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05422132398; Tue, 15 Aug 2017 11:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G_IkqFMbAgDR; Tue, 15 Aug 2017 11:22:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFBF513226B; Tue, 15 Aug 2017 11:22:50 -0700 (PDT)
Received: by with SMTP id u207so9524673ywc.3; Tue, 15 Aug 2017 11:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id f13mr9656855ybh.39.1502821369458; Tue, 15 Aug 2017 11:22:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 15 Aug 2017 11:22:48 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Spencer Dawkins at IETF <>
Date: Tue, 15 Aug 2017 13:22:48 -0500
Message-ID: <>
To: Jean-Marc Valin <>
Cc: The IESG <>,,,,
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-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


On Tue, Aug 15, 2017 at 12:22 PM, Jean-Marc Valin <>

> 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 “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.
> 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’m 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, and
because someone who understands security better than I do is also working
with you on this text!

Thanks for all this.


> Cheers,
>         Jean-Marc