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

You seem to be arguing that there are no security requirements specific for this codec.

I would suggest that the consequence of that is that we do not need RFC 2119 language in this document, and that Ben's language is actually more appropriate. RFC 2119 language should only be used in this area if there is a specific requirement for the codec.

If someone wants to introduce a SHOULD level strength requirement as a result on the perpass discussion, then that should be a separate generic document that updates the document that defines the concept of payload type definitions in the first place (is that currently RFC 4855?).

RFC 7202 is only an informative document and does not contain any requirements in this respect, merely giving guidance.

So if someone wants a normative statement in this respect, assuming one can be written that is actually specific enough to test, then a new document is required, probably from AVTCORE.

Keith

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of 
> Derek Atkins
> Sent: 06 April 2015 17:09
> To: Timothy B. Terriberry
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; 
> iesg@ietf.org; payload-chairs@tools.ietf.org; 
> koenvos74@gmail.com; Derek Atkins
> Subject: Re: [payload] [secdir] sec-dir review of 
> draft-ietf-payload-rtp-opus-08
> 
> "Timothy B. Terriberry" <tterribe@xiph.org> writes:
> 
> > Ben Campbell wrote:
> >>> So my suggestion would be something more to the effect of:
> >>>
> >>> "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.
> >
> > This seems like reasonable text to me. I agree with the 
> rationale that 
> > preceded it. As much as I want to see encryption 
> everywhere, a payload 
> > format is not the right place to mandate it.
> 
> As was stated already in this thread, the expected follow up 
> drafts for MTI security have not been written.
> 
> I leave it up to the Security ADs who have the real power 
> here, but I still prefer my original wording (including the SHOULD).
> 
> I understand your reluctance because it's a codec, but it's 
> the first codec to get through the process since the Perpass 
> work, which basically says "everything should be encrypted."  
> Since you cannot go back in time to modify the existing RFCs, 
> you can augment them going forward by other additions.
> 
> As for the concern about "different security requirements for 
> different codecs", frankly I don't buy that argument.  Either 
> your RTP application supports security or it doesn't.  Once 
> it does, it should be able to negotiate that along side the 
> codec negotitation.  So I don't see the concern -- we're not 
> mandating a specific security technology, just that you 
> SHOULD use one.  Well, that's true regardless of the codec, isn't it?
> 
> Or are you really saying "We don't care about security.  We 
> just want to be able to use this codec in existing, insecure 
> RTP applications without adding new securty measures"?
> 
> -derek
> -- 
>        Derek Atkins                 617-623-3745
>        derek@ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
> 