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

["Derek Atkins" <[e-mail]>]

On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
[snip]
>
> 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:
>
[sniped and added below]
>
> (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.

Okay, so if you want to change the text completely (which I'm fine with),
how about just adding a single sentence to the end of what you have:

   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].
   Applications SHOULD implement at least one of the strong security
   measures suggested by those references.

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

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