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

[Jean-Marc Valin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does anyone object to this earlier proposal?

"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."

If not, that's probably what should go in the RFC (assuming it works
for Kathleen Moriarty's DISCUSS too).

	Jean-Marc

On 07/04/15 06:06 AM, Roni Even wrote:
> 
> 
>> -----Original Message----- From: payload
>> [mailto:[e-mail]] On Behalf Of Colin Perkins 
>> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc:
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; Derek Atkins Subject: Re: [payload] [secdir]
>> sec-dir review of
> draft-ietf-payload-rtp-opus-08
>> 
>> On 6 Apr 2015, at 19:44, Robert Sparks <[e-mail]>
>> wrote:
>>> 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.
>> 
>> +1
>> 
>> As Robert, and others, say, RTP payload format documents are not
>> the right place to mandate security mechanisms. This is the point
>> of RFC7202, which
> is
>> about how strong security can best be defined for classes of RTP
> applications.
>> This is not in conflict with the perpass work, since the goal of
>> RFC7202
> is to
>> show how to provide strong security.
> [Roni Even] What Colin says +1
> 
>> 
>> -- Colin Perkins https://csperkins.org/
>> 
>> 
>> 
>> 
>> _______________________________________________ payload mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/payload
> 
> _______________________________________________ payload mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/payload
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVI8WrAAoJEJ6/8sItn9q9czQH/jWr/wOYnF/Np5pyGT/VVLQ4
CtfYkhfI3FlwZzz0xldUW7pkiiXMXAV99pQHVV85JQ+yBjpYS+TgScoLmlXKftqt
Et41PYxD4MTA/HMqR+ayIXEwu0xLKGKZiCzeI3/4eyJq2yrMa/LoYv0E+2d9+Eow
isDpaXfayJ8OmpAEml52ErJm3bRdvuEioIarVgFqgA+jBg8F01jU34PHcw18ppnK
c93yERmrCK8wDizGYnICrRpdnLojKZ3aR+xfdFGW3JA5XbkGyR3uJc6ACM7r2ap1
UjkYSYviOjSVk2vRnNzqi1pcnTpTjuWxE+GQTJ9o+rr1M3zESWBvYoLVyaenAQg=
=iesF
-----END PGP SIGNATURE-----