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

[Derek Atkins <[e-mail]>]

"Timothy B. Terriberry" <[e-mail]> 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
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant