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

[Robert Sparks <[e-mail]>]

inline (particularly for Derek)

On 4/6/15 11:13 AM, Ben Campbell wrote:
> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
>
>> "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"?
>
> I'm saying this is the wrong layer to solve the problem.
>
> We had some work planned to better specify this in general for RTP. I 
> think the right answer is finish that work. If we do that right, it 
> should apply regardless of codec.
>
That's exactly right.

We've had this conversation several times before. The individual payload 
documents are not the place to add the kind of guidance Derek is asking 
for. They should be about how you put things in RTP, not how 
applications use (and secure RTP), unless there's something unique about 
the payload that interacts with the general mechanics for using and 
securing RTP.

Stephen will remember that we've queued up work on a document that would 
describe securing unicast RTP set up with SDP (capturing the outcome of 
the rtpsec bof at IETF68). The last I heard on the subject Dan Wing was 
taking the token to work on that document, but it's been awhile. That's 
where the effort should focus - an individual payload document is not 
the right place.


>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload