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

[Colin Perkins <[e-mail]>]

On 8 Apr 2015, at 15:24, Derek Atkins <[e-mail]> wrote:
> 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.

And as I keep saying, I believe that is inappropriate, since it's recommending SRTP which is not suitable for many applications. The rtp-howto draft suggests the following text:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC3550, and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].

(The two drafts referenced are what became RFCs 7201 and 7202).

If you want to augment that with a "strong security SHOULD/MUST be used", then I certainly don't object. However, a payload format really shouldn't be trying to recommend use of a particular RTP security solution, such as SRTP.

-- 
Colin Perkins
https://csperkins.org/