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

[Colin Perkins <[e-mail]>]

On 7 Apr 2015, at 16:59, Stephen Farrell <[e-mail]> wrote:
> Hiya,
> 
> Sorry for coming late to this thread (#include <itwasaweekend.h> :-)
> 
> On 06/04/15 19:44, Robert Sparks wrote:
> [...]
>>> 
>>> 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.
> 
> Robert is correct.
> 
>> 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.
> 
> I do recall that now that you mention it. But if it's not actually
> going to happen, then maybe we should rethink the approach, even if
> that'd result in repeated text in payload format drafts.
> 
> Who knows the status of that work?

I don't know the status of that work, but irrespective of that, payload format documents are not the right place to mandate security for RTP. 

An RTP payload format is a media type registration. RTP is a transport protocol. Transport security should be defined for the transport, not for the media type being transported, since there are different ways of transporting the media that can have different security properties. This is the argument of RFC 7202. 

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