Subject: [payload] Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 07 Apr 2015 09:04:51 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-payload-rtp-opus-08: Discuss

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have one thing I'd like to discuss briefly...

cbr=0 (aka vbr) as a default is a security concern since
you're making the less secure option the default. Did the WG
consider that issue when deciding to pick this default?
Given current deployments would it still actually be
feasible to switch the default to cbr? Or would it be
possible to say that cbr is the default for encrypted
traffic but vbr for cleartext?  (Note: I don't plan on
having a big fight about this if it's really too late and
it'd not be possible to change what implementations do for
the default. But even in that case, we might be able to
usefully add some more/better guidance.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 3.1.2: s/_might_ occur/occurs/ the information leak does
occur unquestionably, the only uncertainty is whether or not
someone cares about that, whereas the current text implies
that the leak might not be real. As written, the text is
misleading, though not sufficiently to make this a DISCUSS.
(I am assuming there is no result that shows that encrypted
OPUS traffic is somehow not leaking information in the way
other codecs do.)

- 6.1, maxptime and ptime: I read this as saying that 3, 6,
9 etc are all valid values, but that e.g. 43 is not. Is that
correct? In other words can I mix frames that contain
different durations of audio into one RTP packet? (You may
have told me earlier, but I've forgotten already, sorry:-)

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 07 Apr 2015 16:06:38 -0400

Hi,

Thanks for the review. See comments below.

On 07/04/15 12:04 PM, Stephen Farrell wrote:
> cbr=0 (aka vbr) as a default is a security concern since you're
> making the less secure option the default. Did the WG consider that
> issue when deciding to pick this default? Given current deployments
> would it still actually be feasible to switch the default to cbr?
> Or would it be possible to say that cbr is the default for
> encrypted traffic but vbr for cleartext?  (Note: I don't plan on 
> having a big fight about this if it's really too late and it'd not
> be possible to change what implementations do for the default. But
> even in that case, we might be able to usefully add some
> more/better guidance.)

The cbr= parameter is only a receiver-side preference. The sender can
always send CBR even if the receiver indicates it is okay with
receiving VBR. We need to be aware that in very specific circumstances
VBR may be used to recover information about the audio, but in the
vast majority of cases, there is no such issue. It is certainly no
worse than other information we already give out (VBR video,
unencrypted headers, ...).

As already noted in the draft, RFC6562 already discusses the few cases
where CBR would be more appropriate. In all of these cases, it is the
sender that knows there is an issue, so it really doesn't matter at
all what the receiver uses for cbr=. In general, considering that Opus
is more efficient at VBR than CBR, I believe receivers should be
willing to receive it by default, unless they have a reason to require
the sender to send CBR.

> - 3.1.2: s/_might_ occur/occurs/ the information leak does occur
> unquestionably, the only uncertainty is whether or not someone
> cares about that, whereas the current text implies that the leak
> might not be real. As written, the text is misleading, though not
> sufficiently to make this a DISCUSS. (I am assuming there is no
> result that shows that encrypted OPUS traffic is somehow not
> leaking information in the way other codecs do.)

As far as I'm aware of, the only codec for which information leak from
VBR has ever been measured is Speex (anyone knows of another one?). As
an author on both Speex and Opus, I can at least say that the way the
two do VBR is completely different. Enough so that beyond the very
basic fact that rate changes have entropy, I don't think we can really
use Speex to draw conclusions about Opus. Of course, this is not to
say we should ignore the matter.

> - 6.1, maxptime and ptime: I read this as saying that 3, 6, 9 etc
> are all valid values, but that e.g. 43 is not. Is that correct? In
> other words can I mix frames that contain different durations of
> audio into one RTP packet? (You may have told me earlier, but I've
> forgotten already, sorry:-)

Well, technically 43 is a valid ptime (despite being a dumb thing to
do) if you put 17 frames of 2.5 ms in a packet. OTOH, 6 and 9 and not
valid, since two and three 2.5 ms frames would have ptimes of 5 and 8,
respectively. Note that Opus does not allow mixing frame sizes in the
same packet, so 43 cannot be achieved by 40+2.5 and only by 17*2.5.

Cheers,

	Jean-Marc

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 21:11:53 +0100

On 07/04/15 21:06, Jean-Marc Valin wrote:
> The cbr= parameter is only a receiver-side preference

Ah sorry, thanks - I figure that makes this into a non-blocking
comment. I'll reply fully to your mail and fix that later.

Cheers,
S.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 07 Apr 2015 12:14:39 -0500

Authors: Any thoughts on Stephen's DISCUSS and comments (below)?

Thanks!

Ben.

Forwarded message:

> From: Stephen Farrell <[email-masked]>
> To: The IESG <[email-masked]>
> Cc: [email-masked], 
> [email-masked], [email-masked], 
> [email-masked], [email-masked], 
> [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-payload-rtp-opus-08: 
> (with DISCUSS and COMMENT)
> Date: Tue, 07 Apr 2015 09:04:51 -0700
>
> Please refer to 
> http://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 07 Apr 2015 13:27:29 -0400

I don't think VBR is a significant security issue. We need to be aware
that in very specific circumstances it may leak information, but in the
general case it's quite fine, and certainly no worse than other
information we give out (VBR video, unencrypted headers, ...). As
already noted in the draft, RFC6562 already discusses the few cases
where CBR would be more appropriate. Considering that Opus is more
efficient at VBR, I believe it should be the default. It's also worth
noting that even if VBR=1 is specified by the receiver, there's nothing
that prevents the sender from switching to CBR at any point if needed.

In general, where should we respond to the IESG comments?

Cheers,

	Jean-Marc

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 07 Apr 2015 13:03:56 -0500

> In general, where should we respond to the IESG comments?

Did you get the discuss directly? If so, you can reply-all to that. 
Please make sure the payload list gets copied.

Thanks!

Ben.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 23:37:09 +0100

Hi Jean-Marc,

On 07/04/15 21:06, Jean-Marc Valin wrote:
> The cbr= parameter is only a receiver-side preference. 

As I said earlier, I missed that, but that's good enough to clear
the discuss. (I have balloted no-objection now.)

> The sender can

Fair enough wrt receivers yes.

> say we should ignore the matter.

So I do think it's fair to say that, in principle, any vbr codec
might suffer from such problems. There is a history of researchers
finding such issues, with codecs and more generally with compression.
As 6562 itself notes, attacks only ever get worse. So I think there
is a valid concern. (And the language change suggested above is, I
think, justified.)

But I do get that there's no currently known (to me anyway) reason
to be too concerned with cipphertext carrying opus/vbr, so I'd not
argue that we ought prohibit it or similar.

However I would suggest that there may be a time in future when,
due to someone clever figuring out how to exploit something in
opus/vbr, we might want to move to stop sending opus/vbr/dtls
say. So maybe it'd be wise to add something along the lines of
"While ciphertext carrying opus with vpr is not believed to be
currently exploitable in the ways indicated in RFC 6562, there
may come a day when such an exploit is found. Implementations
ought consider ways in which they could react to such a discovery,
e.g. by ensuring it will be possible to stop using vbr and, from
that point in time, only use cbr, via whatever mechanisms are
appropriate for the implementation concerned." Does that sound
reasonable? (But note this is a non-blocking comment.)

> do) if you put 17 frames of 2.5 ms in a packet. 

Heh. I missed that combination;-)

> OTOH, 6 and 9 and not

That's fine - it does mean what I read it to mean so. No change needed.

Thanks,
S.