Subject: Re: [payload] Spencer Dawkins' No Objection on draft-ietf-payload-rtp-opus-08: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Apr 2015 22:03:53 -0500

On 6 Apr 2015, at 21:34, Spencer Dawkins wrote:

> Spencer Dawkins has entered the following ballot position for
> draft-ietf-payload-rtp-opus-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 
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Meta-comment - it looks like the notification field is pointing only 
> to
> Ali. If that's intentional, rock on, but I've had some
> accidentally-minimal notification lists on drafts recently, and wanted 
> to
> mention that.

I regenerate the notify list for the draft. But since that doesn't 
affect this thread, I manually added at least some of the relevant 
aliases to the CC list.

[...]

>
> In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it
> becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two
> explaining why not using SRTP is the right thing to do.

I mentioned this off-list to Kathleen, but should probably get it on the 
lists:

There is a thread on this topic, triggered by Derek's sec-dir review.

The problem is, that sort of security requirement should be up to RTP 
and the individual application, not the codec. That is, we probably 
don't want a given RTP application to have to worry about differing 
security requirements for different codecs, unless those codecs have 
some unique security implications.

The issue is, the situation for RTP is a bit confused. We have RFCs 7201 
and 7202, which offer some informational guidance. It would be nice to 
have some normative guidance for unicast RTP applications, but that's 
work that needs to be done. So, I think the best thing an RTP payload 
format can do right now is to say something to the effect that Opus 
doesn't offer built-in protection, protection requirements are up to the 
application, and see 7201 and 7202 for discussion. Then we need to do 
whatever we need to do at the RTP application level to encourage the use 
of SRTP.

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Apr 2015 22:05:11 -0500

(Forwarding to additional recipients, due to the notify field issue 
Spencer mentioned below (now fixed.)

On 6 Apr 2015, at 21:34, Spencer Dawkins wrote:

> This draft seemed very clear to me, one not skilled in the art. Thank 
> you
> for that.
>
> I have a few comments. If you have questions, please ask, but they're
> non-blocking (so do the right thing).
>
> In this text:
>
> 3.  Opus Codec
>
>  Further, Opus allows transmitting stereo signals.
>
> I wasn't sure what this was telling me until I got to section 3.4, and
> saw this text: "signaled in-band in the Opus payload". Perhaps adding
> that phrase in Section 3 would be helpful?
>
> In this text:
>
> 3.1.2.  Variable versus Constant Bitrate
>
>  One
>  reason for choosing CBR is the potential information leak that
>  _might_ occur when encrypting the compressed stream.  See [RFC6562]
>  for guidelines on when VBR is appropriate for encrypted audio
>  communications.
>
> I THINK I know what "potential information leak" means in this case, 
> but
> I'm guessing. I learned a lot from the [RFC6562] reference. Is it
> possible to provide a short clue here? Would it be correct to say
> something like "One reason for choosing CBR is that some codecs have 
> been
> observed to provide predictable VBR patterns for highly structured
> dialogs where only a few phrases are expected, and potentially leaking
> information without requiring an eavesdropper to decrypt the payload"?
>
> Also in 3.1.2:
>
>  The bitrate can be adjusted at any point in time.  To avoid
>  congestion, the average bitrate SHOULD NOT exceed the available
>  network bandwidth.
>
> I'm kind of wondering how you intend for the sender to know what the
> "available network bandwidth" is. I notice a reference in Section 3.3 
> to
>
>
>  (2) an externally-provided estimate of the
>  channel's capacity;
>
> Is "the available network bandwidth" this externally provided 
> estimate?
> What should a sender be looking at, to fulfill this SHOULD NOT?
>
> Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. 
> Is
> this recognizing that available network bandwidth can change
> instantaneously (so a careful sender might still find itself sending 
> too
> fast for a short period of time), or is there something else going on?
>
> As long as I'm mentioning section 3.3, if the "externally-provided
> estimate" had some reference, that would be helpful (unless, of 
> course,
> this is obvious to those skilled in the art). The term only appears 
> twice
> in 3.3, with no pointers.
>
> In this text:
>
> 5.  Congestion Control
>
>  It is RECOMMENDED that senders of Opus encoded data apply congestion
>  control.
>
> Is there a particular mechanism you're thinking of here? If you could
> make that clearer, even just providing a reference, that would be 
> helpful
> for me as a reader.
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Apr 2015 22:07:52 -0500

(... and trying again. Sorry for the repeat;shepherd had too many "L"s)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 6 Apr 2015 22:12:01 -0500

Hi, Ben,

On Mon, Apr 6, 2015 at 10:07 PM, Ben Campbell <[email-masked]> wrote:

>> email addresses included in the To and CC lines. (Feel free to cut this
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> Meta-comment - it looks like the notification field is pointing only to
>> accidentally-minimal notification lists on drafts recently, and wanted to
>> mention that.
>>
>> This draft seemed very clear to me, one not skilled in the art. Thank you
>> for that.
>>
... deleted down to ...

>> explaining why not using SRTP is the right thing to do.
Your explanation in private e-mail makes perfect sense to me, and the
responsible parties can safely ignore that part of my comment.

Thanks!

Spencer

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 08 Apr 2015 16:30:51 -0400

> I wasn't sure what this was telling me until I got to section 3.4, and saw this
> text: "signaled in-band in the Opus payload". Perhaps adding that phrase in
> Section 3 would be helpful?

I can change to "Further, Opus allows transmitting stereo signals with
in-band signaling". I'd rather avoid the term "payload" here since the
signaling is defined in Opus itself rather than the RTP payload format.

> I THINK I know what "potential information leak" means in this case, but I'm
> guessing. I learned a lot from the [RFC6562] reference. Is it possible to
> provide a short clue here? Would it be correct to say something like "One
> reason for choosing CBR is that some codecs have been observed to provide
> predictable VBR patterns for highly structured dialogs where only a few phrases
> are expected, and potentially leaking information without requiring an
> eavesdropper to decrypt the payload"?

Ideally I would rather avoid attempting to summarize RFC6562 in just one
or two sentences. I think we managed to strike roughly the right balance
in RFC6562 and it would be easy to create confusion by attempting to
address the issue in this document too.

> I'm kind of wondering how you intend for the sender to know what the "available
> network bandwidth" is. I notice a reference in Section 3.3 to
> 
> Is "the available network bandwidth" this externally provided estimate? What
> should a sender be looking at, to fulfill this SHOULD NOT?

As I pointed out in my response to Barry Leiba, there's no specific
"recipe" we can put in. The goal is mostly to raise awareness of the
bandwidth issue.

> Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. Is this
> recognizing that available network bandwidth can change instantaneously (so a
> careful sender might still find itself sending too fast for a short period of
> time), or is there something else going on?

I don't think there's even an exact definition of "available network
bandwidth", or at least not a precise measurement, so MUST NOT wouldn't
make much sense.

> As long as I'm mentioning section 3.3, if the "externally-provided estimate"
> had some reference, that would be helpful (unless, of course, this is obvious
> to those skilled in the art). The term only appears twice in 3.3, with no
> pointers.

It is certainly not something obvious. I believe rmcat is working on
some sort of solution (not familiar with the details), so I'm not sure
what else I can add here.

> Is there a particular mechanism you're thinking of here? If you could make that
> clearer, even just providing a reference, that would be helpful for me as a
> reader.

Again, all I can think of here would be to point to some rmcat work.

> In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it becomes a
> SHOULD and not a MUST, I'd suggest adding a sentence or two explaining why not
> using SRTP is the right thing to do.

Waiting on a consensus on the exact text to put here. I have no strong
opinion on what exactly should go there.

Cheers,

	Jean-Marc

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Apr 2015 21:36:05 +0100

> address the issue in this document too.

I think I'd agree with Jean-Marc on that one. The actual
attack, when possible, is fairly subtle, esp if it affects
people speaking. (Way back, I had a DISCUSS on what became
6562 where it took a couple of months for us all to get on
the same page about that;-)

S.