Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08

[Derek Atkins <[e-mail]>]

Colin, et all,

I suggest you take a closer look at the existing document.  In
particular, I do not accept the argument that this is the wrong place to
recommend security, because the existing draft already does.  See below:

Colin Perkins <[e-mail]> writes:

> On 8 Apr 2015, at 01:12, Kathleen Moriarty <[e-mail]>
> wrote:
>
>     On Tue, Apr 7, 2015 at 10:42 AM, Derek Atkins <[e-mail]> wrote:
>    
>         Hi,
>        
>         Jean-Marc Valin <[e-mail]> writes:
>        
>         > Does anyone object to this earlier proposal?
>         >
>         > "Opus does not provide any built-in confidentiality or integrity
>         > protection. Protection requirements vary between RTP applications.
>         See
>         > RFC 7201 and RFC 7202 for a discussion."
>
>     I'm okay with this text and did read the subsequent messages in this
>     thread.  Since there is a MAY already for session encryption, that's why
>     we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119
>     language, but having some generic advice about RTP payloads.  Since there
>     is no draft ready or in the works to fix this problem where it should be
>     fixed, I do think it's a good idea to address the concern here and going
>     forward.  Once it's fixed int eh right place, then references and text
>     changes going forward.
>
> There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and
> A.13 for payload format text. That draft is in the RFC Editor queue, but I'm
> sure Magnus would be pleased to receive feedback if the suggestions there are
> not clear.

Let me quote a section of the draft, in particular section 8. Security
Considerations:

   This payload format transports Opus encoded speech or audio data.
   Hence, security issues include confidentiality, integrity protection,
   and authentication of the speech or audio itself.  Opus does not
   provide any confidentiality or integrity protection.  Any suitable
   external mechanisms, such as SRTP [RFC3711], MAY be used.

So this draft already DOES make a recommendation about the transport
layer security.  I was saying that you should change this MAY to a
SHOULD, which is where this all started.

You may say "this is the wrong layer", but from where I sit that horse
has already left the barn.  The WG already let it pass with this
recommendation as a MAY.  As a memeber of the Security Area Directorate
I think this MAY should be changed to a SHOULD.

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant