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

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Apr 2015 15:33:38 -0500

([email-masked])

I just noticed this thread is has included the payload mail list. Since 
the discussion involves potential material changes (i.e. normative 
language changes) , the working group should at least see it.

/Ben.

On 1 Apr 2015, at 17:50, Ben Campbell wrote:

> On 1 Apr 2015, at 16:20, Jean-Marc Valin wrote:
>
>> Based on Derek's latest suggestion, the text would become:
>>
>> "Since Opus does not provide any confidentiality or integrity
>> protection, implementations SHOULD use one of the possible RTP
>> Security methods (See RFC7201, RFC7202)."
>>
>> I think that should resolve the issue that was raised.
>
> I'm not sure that's the right solution. First, 7201 and 7202 are 
> informational, so I'm not sure we want to insert a normative reference 
> to them here.
>
> But more to the point, while I concur with the desire to push for 
> better protections, I don't think a codec payload spec is the right 
> place to do it. It risks having different security requirements for 
> different codecs when used by the same RTP application. I can see that 
> if there are really security difference (e.g. if some codec had built 
> in protection.)
>
> I think this is rather the point of 7202, although I notice section 6 
> of that draft says: "It is also expected that a similar [MTI crypto 
> spec] will be produced for voice-over-IP applications using SIP and 
> RTP." Unfortunately, I don't think that ever happened.
>
> 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.
>
>>
>> 	Jean-Marc
>>
>> On 01/04/15 05:11 PM, Ben Campbell wrote:
>>> Hi Roni and Derek,
>>>
>>> This thread sort of tailed off in February. Has the discussion been
>>> resolved?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On 19 Feb 2015, at 11:07, Derek Atkins wrote:
>>>
>>>> Roni,
>>>>
>>>> I'm not an RTP guy.  To me "SRTP" is a general class of "Secure
>>>> RTP" protocols.  So let's work on that as my starting point:
>>>> implementations SHOULD protect their RTP stream.
>>>>
>>>> Based on that, how about a re-wording here?  Instead of just
>>>> saying "MAY use SRTP", how about something like "SHOULD use one
>>>> of the possible RTP Security methods (See RFC7201, RFC7202)"?
>>>> (Obviously this can be worded better).
>>>>
>>>> -derek
>>>>
>>>> Roni Even <[email-masked]> writes:
>>>>
>>>>> Hi, The reason for the may is discussed in RFC7201 and RFC
>>>>> 7202, it can be a SHOULD and these RFCs exaplain when it is not
>>>>> required to use SRTP. Maybe add a reference to these RFCs in
>>>>> the security section when saying talking about good reasons for
>>>>> not using SRTP
>>>>>
>>>>> Roni Even
>>>>>
>>>>> ________________________________________ From: Jean-Marc Valin
>>>>> [[email-masked]] on behalf of Jean-Marc Valin
>>>>> [[email-masked]] Sent: Tuesday, February 17, 2015 10:23
>>>>> PM To: Derek Atkins; [email-masked]; [email-masked] Cc:
>>>>> [email-masked]; [email-masked];
>>>>> [email-masked] Subject: Re: sec-dir review of
>>>>> draft-ietf-payload-rtp-opus-08
>>>>>
>>>>> Hi Derek,
>>>>>
>>>>> There was no particular reason for the MAY, the text was merely
>>>>> copied from other RTP payload RFC. I totally agree with making
>>>>> it a SHOULD.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jean-Marc
>>>>>
>>>>> On 17/02/15 02:54 PM, Derek Atkins wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have reviewed this document as part of the security
>>>>>> directorate's ongoing effort to review all IETF documents
>>>>>> being processed by the IESG.  These comments were written
>>>>>> with the intent of improving security requirements and
>>>>>> considerations in IETF drafts.  Comments not addressed in
>>>>>> last call may be included in AD reviews during the IESG
>>>>>> review.  Document editors and WG chairs should treat these
>>>>>> comments just like any other last call comments.
>>>>>>
>>>>>> Summary:
>>>>>>
>>>>>> Ready to publish with a question: I question why the use of
>>>>>> SRTP is a MAY and not a SHOULD (as detailed in the Security
>>>>>> Considerations section).  Considering PERPASS I believe this
>>>>>> should be a SHOULD; someone should have a very good reason
>>>>>> why they are NOT using SRTP.
>>>>>>
>>>>>> Details:
>>>>>>
>>>>>> This document defines the Real-time Transport Protocol (RTP)
>>>>>> payload format for packetization of Opus encoded speech and
>>>>>> audio data necessary to integrate the codec in the most
>>>>>> compatible way. Further, it describes media type
>>>>>> registrations for the RTP payload format.
>>>>>>
>>>>>> I have no other comments on this document.
>>>>>>
>>>>>> -derek
>>>>>>
>>>>>
>>>>> _______________________________________________ secdir mailing
>>>>> list [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/secdir wiki:
>>>>> http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>>>>
>>>>>
>>>>
>>>> -- Derek Atkins                 617-623-3745 [email-masked]
>>>> www.ihtfp.com Computer and Internet Security Consultant

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 03 Apr 2015 13:44:12 -0700

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

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 03 Apr 2015 16:15:52 -0500

On 3 Apr 2015, at 15:33, Ben Campbell wrote:

> I just noticed this thread is has included the payload mail list.

Oops, I meant to say has _not_ included...

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 06 Apr 2015 11:13:30 -0500

On 6 Apr 2015, at 11:09, Derek Atkins wrote:

> "Timothy B. Terriberry" <[email-masked]> writes:
>
>> Ben Campbell wrote:
> 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.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 06 Apr 2015 13:44:30 -0500

inline (particularly for Derek)

On 4/6/15 11:13 AM, Ben Campbell wrote:
>> As was stated already in this thread, the expected follow up drafts for
>> 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
>> concern -- we're not mandating a specific security technology, just that
>> 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
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Colin Perkins <[email-masked]>
Date: Mon, 6 Apr 2015 19:50:23 +0100

On 6 Apr 2015, at 19:44, Robert Sparks <[email-masked]> wrote:
>> 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.

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

---

From: "Roni Even" <[email-masked]>
Date: Tue, 7 Apr 2015 13:06:05 +0300

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: 06 April, 2015 9:50 PM
> To: Robert Sparks
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Derek Atkins
> Subject: Re: [payload] [secdir] sec-dir review of
> >>>> 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.
> >>>
> >>> 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.
> >>>
> >>> 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"?
> >>
think
> the right answer is finish that work. If we do that right, it should apply
> regardless of codec.
> >>
> > That's exactly right.
> >
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.
> >
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

---

From: Derek Atkins <[email-masked]>
Date: Mon, 06 Apr 2015 12:09:26 -0400

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 16:59:39 +0100

Hiya,

Sorry for coming late to this thread (#include <itwasaweekend.h> :-)

On 06/04/15 19:44, Robert Sparks wrote:
[...]
> the payload that interacts with the general mechanics for using and

Robert is correct.

> where the effort should focus - an individual payload document is not

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?

S.

> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 07 Apr 2015 11:08:03 -0500

> Who knows the status of that work?

I am trying to track that down. But I am working under the assumption it 
didn't go anywhere.

But I'd rather try to revive that work than to take a piecemeal approach 
of adding it to payload drafts. That doesn't help with pre-existing 
payload formats, and I think asking RTP application designers to treat 
privacy requirements on a per-codec basis is untenable. I suspect the 
best we could expect out of that is for people to ignore us.

If we can agree to leave this out of payload drafts, I will track down 
and try really hard to restart the RTP level effort.

/Ben

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 17:12:29 +0100

Thanks Ben,

> and try really hard to restart the RTP level effort.

Yes, that'd definitely be the best approach. I do get how it's
not so easy to motivate someone to get it done though, but maybe
another push at it will work. I'm happy to help as I can as well
too.

Cheers,
S.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 7 Apr 2015 16:15:55 +0000

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

> From: payload [mailto:[email-masked]] On Behalf Of 
> Derek Atkins
> Sent: 06 April 2015 17:09
> To: Timothy B. Terriberry
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; Derek Atkins
> 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.
> 
> 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
> --

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 07 Apr 2015 07:55:26 -0400

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:[email-masked]] On Behalf Of Colin Perkins 
>> Sent: 06 April, 2015 9:50 PM To: Robert Sparks Cc:
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; Derek Atkins Subject: Re: [payload] [secdir]
>> sec-dir review of
>>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben
>>> Campbell wrote:
>>>>>>>> "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.
>>>>> 
>>>>> 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 
>>>>> just want to be able to use this codec in existing,
>>>>> insecure RTP applications without adding new securty
>>>>> measures"?
>>>> 
>> the right answer is finish that work. If we do that right, it
>> 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
>> -- Colin Perkins https://csperkins.org/
>> 
>> 
>> 
>> 
>> _______________________________________________ payload mailing
>> list [email-masked] 
> _______________________________________________ payload mailing
> list [email-masked]

---

From: "Roni Even" <[email-masked]>
Date: Tue, 7 Apr 2015 16:33:18 +0300

Hi Jean-Marc,
I think this sounds good, I suggest also to mention RFC6562 
Roni

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: 07 April, 2015 2:55 PM
> To: Roni Even; 'Colin Perkins'; 'Robert Sparks'
> [email-masked]; [email-masked]; 'Derek Atkins'
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
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
> 
> >> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> >>> inline (particularly for Derek) On 4/6/15 11:13 AM, Ben Campbell
> >>> wrote:
> >>>>>>>> "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.
> >>>>>>
> >>>>>> that preceded it. As much as I want to see encryption everywhere,
> >>>>>> a payload format is not the right place to mandate it.
> >>>>>
> >>>>> I leave it up to the Security ADs who have the real power here,
> >>>>> but I still prefer my original wording (including the SHOULD).
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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?
> >>>>>
> >> the right answer is finish that work. If we do that right, it should
> >> apply regardless of codec.
> >>>>
> >>> That's exactly right.
> >>>
> >> 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
> list
> >> [email-masked] https://www.ietf.org/mailman/listinfo/payload
> >
> > _______________________________________________ payload mailing list
> > [email-masked] 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-----

---

From: Derek Atkins <[email-masked]>
Date: Tue, 07 Apr 2015 10:42:59 -0400

Hi,

> for Kathleen Moriarty's DISCUSS too).

It's not quite as strong a statement as I'd like to see, but if Kathleen
is okay with it then I'm okay with it.

-derek

---

From: Colin Perkins <[email-masked]>
Date: Tue, 7 Apr 2015 17:23:33 +0100

> 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/

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Apr 2015 20:12:19 -0400

> > RFC 7201 and RFC 7202 for a discussion."

I'm okay with this text and did read the subsequent messages in this
thread.  Since there is a MAY already for session encryption, that's why we
were inserting a SHOULD.  I'm fine with getting rid of the RFC2119
language, but having some generic advice about RTP payloads.  Since there
is no draft ready or in the works to fix this problem where it should be
fixed, I do think it's a good idea to address the concern here and going
forward.  Once it's fixed int eh right place, then references and text
changes going forward.

Thanks for the discussion on this.

Kathleen

-- 

Best regards,
Kathleen

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Apr 2015 10:08:14 +0100

On 8 Apr 2015, at 01:12, Kathleen Moriarty <[email-masked]> wrote:
> I'm okay with this text and did read the subsequent messages in this thread.  Since there is a MAY already for session encryption, that's why we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119 language, but having some generic advice about RTP payloads.  Since there is no draft ready or in the works to fix this problem where it should be fixed, I do think it's a good idea to address the concern here and going forward.  Once it's fixed int eh right place, then references and text changes going forward.

There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and A.13 for payload format text. That draft is in the RFC Editor queue, but I'm sure Magnus would be pleased to receive feedback if the suggestions there are not clear.

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Apr 2015 15:35:02 +0100

On 8 Apr 2015, at 15:24, Derek Atkins <[email-masked]> wrote:
> Colin, et all,
> 
> I suggest you take a closer look at the existing document.  In
> particular, I do not accept the argument that this is the wrong place to
> recommend security, because the existing draft already does.  See below:
> 
> Colin Perkins <[email-masked]> writes:
> 
>>        See
>>    thread.  Since there is a MAY already for session encryption, that's why
>>    we were inserting a SHOULD.  I'm fine with getting rid of the RFC2119
>> There is some guidance in draft-ietf-payload-rtp-howto-13 sections 7.2 and
>> A.13 for payload format text. That draft is in the RFC Editor queue, but I'm
>> sure Magnus would be pleased to receive feedback if the suggestions there are
>> not clear.
> 
> Let me quote a section of the draft, in particular section 8. Security
> Considerations:
> 
>   This payload format transports Opus encoded speech or audio data.
>   Hence, security issues include confidentiality, integrity protection,
>   and authentication of the speech or audio itself.  Opus does not
>   provide any confidentiality or integrity protection.  Any suitable
>   external mechanisms, such as SRTP [RFC3711], MAY be used.
> 
> So this draft already DOES make a recommendation about the transport
> layer security.  I was saying that you should change this MAY to a
> SHOULD, which is where this all started.
> 
> You may say "this is the wrong layer", but from where I sit that horse
> has already left the barn.  The WG already let it pass with this
> recommendation as a MAY.  As a memeber of the Security Area Directorate
> I think this MAY should be changed to a SHOULD.

And as I keep saying, I believe that is inappropriate, since it's recommending SRTP which is not suitable for many applications. The rtp-howto draft suggests the following text:

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC3550, and in any applicable RTP profile such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
   SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
   Why RTP Does Not Mandate a Single Media Security Solution"
   [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
   formats responsibility to discuss or mandate what solutions are used
   to meet the basic security goals like confidentiality, integrity and
   source authenticity for RTP in general.  This responsibility lays on
   anyone using RTP in an application.  They can find guidance on
   available security mechanisms and important considerations in Options
   for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].

(The two drafts referenced are what became RFCs 7201 and 7202).

If you want to augment that with a "strong security SHOULD/MUST be used", then I certainly don't object. However, a payload format really shouldn't be trying to recommend use of a particular RTP security solution, such as SRTP.

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

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Apr 2015 10:24:39 -0400

Colin, et all,

Thanks,

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 8 Apr 2015 10:42:59 -0400

On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
[snip]
>
> And as I keep saying, I believe that is inappropriate, since it's
> recommending SRTP which is not suitable for many applications. The
> rtp-howto draft suggests the following text:
>
[sniped and added below]
> If you want to augment that with a "strong security SHOULD/MUST be used",
> then I certainly don't object. However, a payload format really shouldn't
> be trying to recommend use of a particular RTP security solution, such as
> SRTP.

Okay, so if you want to change the text completely (which I'm fine with),
how about just adding a single sentence to the end of what you have:

   Applications SHOULD implement at least one of the strong security
   measures suggested by those references.

-derek

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Apr 2015 13:52:43 -0500

>  measures suggested by those references.

I'm okay with using the rtp-howto text. But _strictly_as_an_individual_, 
I'd prefer not to add the last sentence, for 2 reasons:

1) This effectively creates a normative downref to informational RFCs 
(7201/7202). That's mainly a process issue, and we can do that if it's 
the right thing to do. But...

2) ... I still don't think a payload format is the right place to put 
this sort of thing (that is, the last sentence.) Now, if our plan is to 
put that text into all future payload formats, that's not quite as bad. 
But unless we plan to revise legacy formats, it still creates confusing 
inconsistency between formats.

For an extreme example, having that sentence in Codec format A and not 
format B could lead to implementor decisions on the order of "I don't 
want to bother with crypto, so I will choose codec B because it has 
lighter requirements" might appear to make sense to someone not steeped 
in this argument.

What I'd _really_ like to do is take the energy in this thread and apply 
it to creating a standards-track security document for RTP unicast 
applications.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Apr 2015 14:49:05 -0500

On 8 Apr 2015, at 14:38, Derek Atkins wrote:

> Ben,
>
> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> It's technically not a downref because the referred documents are 
> guidance
> and not protocols.  So I don't think there would be any issue.  There 
> is
> already precedent for that.

As I said, it's just process.

> I'll point out, again, that the original draft *already did this*, so 
> you
> should be talking to the working group about that and not to me.  From
> where I sit, I saw the "MAY encrypt" and said "please change that from 
> MAY
> to SHOULD."  That's where this all started.
>
> Now, you could say (possibly even correctly -- I wont make that 
> judgement
> call) that the WG made a mistake putting that sentence into the 
> Security
> Considerations at all in the first place, but they did.  Clearly the 
> WG
> decided it was worthwhile to mention that; I'm just suggesting to make 
> the
> mention stronger than what was there in -08.

I'm not convinced. SHOULD is considerably more constraining that MAY.

> Are you willing to hold up this document until that work is done so it 
> can
> refer to the (yet-to-be-written) protocol security update draft?  I'm 
> fine
> with that approach and I'm willing to review whatever draft you guys
> produce if that's how you'd like to proceed.

No, I will go with the consensus on this one. I note that several WG 
participants objected to the orignally proposed SHOULD. I am pointing 
out that this SHOULD is not much different, but I will go with what 
people want to do.

OTOH, what I would like to do would fix the problem for this, and all 
other codec payload formats, after the fact if we do it right (since it 
would apply to the application)

>
> Or you can hold your nose and live with the "UGGH" of it based on what 
> the
> WG original created in -08 and move forward for now, knowing that you 
> can
> (and should) correct it "right" later.

The work group did not put in a SHOULD. I think this is more of a 
question of whether people are willing to hold there collective noses 
about the lack of _normative_ privacy guidance for RTP in general, and 
if they are willing to let payload formats continue to progress while 
that is being worked out.

>
> I have no skin in that decision :)
>
> -derek
> --

---

From: Colin Perkins <[email-masked]>
Date: Thu, 9 Apr 2015 10:58:17 +0100

>>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
...snip...
>> Are you willing to hold up this document until that work is done so it can
>> refer to the (yet-to-be-written) protocol security update draft?  I'm fine
> No, I will go with the consensus on this one. I note that several WG participants objected to the orignally proposed SHOULD. I am pointing out that this SHOULD is not much different, but I will go with what people want to do.

I think "SHOULD use an appropriate strong security mechanism" is quite different to "SHOULD use SRTP", since we know of cases where SRTP isn't suitable. That was my objection to the original text.

> OTOH, what I would like to do would fix the problem for this, and all other codec payload formats, after the fact if we do it right (since it would apply to the application)
> 
>> 
>> Or you can hold your nose and live with the "UGGH" of it based on what the
>> WG original created in -08 and move forward for now, knowing that you can
> The work group did not put in a SHOULD. I think this is more of a question of whether people are willing to hold there collective noses about the lack of _normative_ privacy guidance for RTP in general, and if they are willing to let payload formats continue to progress while that is being worked out.

One of the things RFC 7202 tries to convey is that "normative privacy guidance for RTP in general" is not possible. The privacy requirements, for example, of broadcast TV are different to those for a phone call, but both can use RTP. 

A document giving normative security guidance for unicast SIP-based telephony using RTP is something we need, I agree. I'm happy to help reviewing such a thing, but it should be authored by someone more familiar with the deployed security mechanisms.

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Apr 2015 11:04:27 +0100

I do agree with Colin here (and with Ben and Robert) but...

On 09/04/15 10:58, Colin Perkins wrote:
> A document giving normative security guidance for unicast SIP-based
> telephony using RTP is something we need, I agree. I'm happy to help
> reviewing such a thing, but it should be authored by someone more
> familiar with the deployed security mechanisms.

I've just gotten offlist mail from another secdir reviewer who
noted that we had exactly the same discussion 7 years ago for
another payload document. And I recall it myself more recently.

So that unicast SIP/RTP document really would save us all some
time and might help those implementing and deploying security
stuff in such cases. (And even if folks were not implementing
or deploying security stuff for this 7 years ago, I would say
that it's much more likely they will be doing that today and
in future.)

S.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 9 Apr 2015 11:11:08 +0100

> another payload document. And I recall it myself more recently.

We've been around this loop multiple times. That's why we wrote RFCs 7201 and 7202, to try to stop repeating the same discussion by explaining the issues and providing guidance. The recommended text for new RTP payload formats in the rtp-howto was also intended to help clarify. Clearly something more is needed. If the issue is that RFC7202 isn't clear, then I'm happy to work with someone to clarify in an update, but I suspect we need the suggested documents giving normative requirements for different application classes.

> that it's much more likely they will be doing that today and

Agreed.

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 Apr 2015 16:59:12 +0100

>   measures suggested by those references.

Sure, that's fine (Magnus might want to update the rtp-howto with that extra text too).

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

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 8 Apr 2015 15:38:13 -0400

Ben,

> the right thing to do. But...

It's technically not a downref because the referred documents are guidance
and not protocols.  So I don't think there would be any issue.  There is
already precedent for that.

> inconsistency between formats.

I'll point out, again, that the original draft *already did this*, so you
should be talking to the working group about that and not to me.  From
where I sit, I saw the "MAY encrypt" and said "please change that from MAY
to SHOULD."  That's where this all started.

Now, you could say (possibly even correctly -- I wont make that judgement
call) that the WG made a mistake putting that sentence into the Security
Considerations at all in the first place, but they did.  Clearly the WG
decided it was worthwhile to mention that; I'm just suggesting to make the
mention stronger than what was there in -08.

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Apr 2015 20:49:17 +0100

> it to creating a standards-track security document for RTP unicast

Fully agree that, if it's achievable, that is better.

As with Derek, I'm not objecting to this draft handling this
either with Derek's latest suggested SHOULD, nor with the
original, nor if it ends up tweaked to match other payload
specs.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 8 Apr 2015 16:39:58 -0400

Sent from my iPhone

> On Apr 8, 2015, at 3:49 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Sorry I've been tied up in meetings.   Where are we at with text changes for this draft versus what's planned in another draft?  It would be good to clear my discuss before tomorrow if we can.

Thanks,
Kathleen

---

From: "Roni Even" <[email-masked]>
Date: Thu, 9 Apr 2015 13:10:34 +0300

Hi,
I support what Colin says about SRTP being a security tool for unicast
telephony but other applications including multicast and broadcast that use
RTP may use other security mechanism.
Defining security for media in a specific application may be done when
defining the application like in RTCweb
(https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23 section 4.2)
Roni Even

> Sent: 09 April, 2015 12:58 PM
> To: Ben Campbell
> Cc: [email-masked]; [email-masked]; [email-masked]; Kathleen
Moriarty;
> [email-masked]; [email-masked]; [email-masked]; Derek
> Atkins
> >>> For an extreme example, having that sentence in Codec format A and
> >>> not format B could lead to implementor decisions on the order of "I
> >>> don't want to bother with crypto, so I will choose codec B because
> >>> it has lighter requirements" might appear to make sense to someone
> >>> not steeped in this argument.
> >>>
> >>> What I'd _really_ like to do is take the energy in this thread and
> >>> apply it to creating a standards-track security document for RTP
> >>> unicast applications.
> >>
> >> Are you willing to hold up this document until that work is done so
> >> it can refer to the (yet-to-be-written) protocol security update
> >> draft?  I'm fine with that approach and I'm willing to review
> >> whatever draft you guys produce if that's how you'd like to proceed.
> >
> participants objected to the orignally proposed SHOULD. I am pointing out
that
> this SHOULD is not much different, but I will go with what people want to
do.
> 
> I think "SHOULD use an appropriate strong security mechanism" is quite
> different to "SHOULD use SRTP", since we know of cases where SRTP isn't
> suitable. That was my objection to the original text.
> 
> > other codec payload formats, after the fact if we do it right (since
> > it would apply to the application)
> >
> >>
> >> Or you can hold your nose and live with the "UGGH" of it based on
> >> what the WG original created in -08 and move forward for now, knowing
> >> that you can (and should) correct it "right" later.
> >
question of
> whether people are willing to hold there collective noses about the lack
of
> _normative_ privacy guidance for RTP in general, and if they are willing
to let
> payload formats continue to progress while that is being worked out.
> 
> One of the things RFC 7202 tries to convey is that "normative privacy
guidance
> for RTP in general" is not possible. The privacy requirements, for
example, of
> broadcast TV are different to those for a phone call, but both can use
RTP.
> A document giving normative security guidance for unicast SIP-based
telephony
> using RTP is something we need, I agree. I'm happy to help reviewing such
a
> thing, but it should be authored by someone more familiar with the
deployed
> security mechanisms.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 08:24:32 -0500

On 9 Apr 2015, at 4:58, Colin Perkins wrote:

> guidance for RTP in general" is not possible. The privacy 
> requirements, for example, of broadcast TV are different to those for 
> a phone call, but both can use RTP.
>

Sorry, I mean for unicast. I just dropped the word when typing :-)

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 08:41:01 -0500

On 9 Apr 2015, at 5:11, Colin Perkins wrote:

> We've been around this loop multiple times. That's why we wrote RFCs 
> 7201 and 7202, to try to stop repeating the same discussion by 
> explaining the issues and providing guidance. The recommended text for 
> new RTP payload formats in the rtp-howto was also intended to help 
> clarify. Clearly something more is needed. If the issue is that 
> RFC7202 isn't clear, then I'm happy to work with someone to clarify in 
> an update, but I suspect we need the suggested documents giving 
> normative requirements for different application classes.

The problem is not that 7202 is not clear. It "clearly" says that the 
each class of RTP application needs to specify MTI strong security. The 
problem is that no such specification exists for SIP-based RTP unicast 
applications. So saying we SHOULD follow 7202 doesn't really help.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 08:45:05 -0500

On 9 Apr 2015, at 8:31, Derek Atkins wrote:

>> different to "SHOULD use SRTP", since we know of cases where SRTP
>> isn't suitable. That was my objection to the original text.
>
> I'm fine with "SHOULD use an appropriate strong security mechanism",
> which is what I tried to convey with my added sentence to the guidance
> paragraph.

I would be okay with "SHOULD use an appropriate strong security 
mechanism". I assume the intended difference is the removal of the "as 
suggested by those references" part.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 09:07:55 -0500

On 9 Apr 2015, at 9:00, Derek Atkins wrote:

> Ben,
>
> On Thu, April 9, 2015 9:45 am, Ben Campbell wrote:
> So you're suggesting (and would be okay with) this text:
>
>  Applications SHOULD use an appropriate strong security mechanism.
>

I am okay with that text.

> I think I'm okay with this.  (I kind of prefer my previous wording,
> "Applications SHOULD implement at least one of the strong security
> measures suggested by those references" only because it suggests that
> multiple mechanisms are okay, whereas this new wording seems to imply
> choosing only one).

How about "Applications SHOULD use one or more strong security 
mechanisms, as appropriate"?

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 09:21:57 -0500

On 9 Apr 2015, at 9:19, Derek Atkins wrote:

> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
> Clearly now we're just getting down to wordsmithing..  :)

Yeah, we should probably let the authors wordsmith their own draft :-)

>
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
>
> What say you?

WFM

---

From: Derek Atkins <[email-masked]>
Date: Thu, 09 Apr 2015 09:31:43 -0400

-derek

---

From: Derek Atkins <[email-masked]>
Date: Thu, 09 Apr 2015 09:32:53 -0400

Hi,

Kathleen Moriarty <[email-masked]> writes:

> Sorry I've been tied up in meetings.  Where are we at with text
> changes for this draft versus what's planned in another draft?  It
> would be good to clear my discuss before tomorrow if we can.

We have some proposed text (which was a sentence I added to a paragraph
that came from the guidance document), but I don't know if we've come to
consensus on that suggestion.

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 9 Apr 2015 10:00:29 -0400

Ben,

-derek

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Apr 2015 08:55:15 -0500

I think we have a general agreement for text that talks about how the 
choice of MTI security depends on the RTP application class. There's an 
ongoing discussion as to whether that should include something to the 
effect of "SHOULD implement appropriate protections".

I seemed to be the principle nay-sayer as of this morning, and I'm okay 
with Derek's latest suggestion, so I _think_ people are very close to an 
agreement on exact language.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 9 Apr 2015 10:19:35 -0400

[snip]

What say you?

-derek

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 9 Apr 2015 10:24:32 -0400

> > modifies the "strong security mechanism" and not the "SHOULD use"  ;)

This text works for me as well.  Please let me know once the draft has been
updated and thanks for the discussion on this point.

Kathleen

-- 

Best regards,
Kathleen

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 09 Apr 2015 10:27:27 -0400

> Yeah, we should probably let the authors wordsmith their own draft

Actually, on that one I'd rather not wordsmith myself. If there's
consensus on exact text, I'd rather just put it in as-is.

	Jean-Marc

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Apr 2015 08:56:21 +0200

> modifies the "strong security mechanism" and not the "SHOULD use"  ;)

Yes, I think that is fine. I don't see this contradicting RFC7202, and
are happy to include this in draft-ietf-payload-rtp-howto's template
text. I will wait a week before submitting an update version of the
HOWTO with this text and updated references. I will send an separate
email to the list and IESG to make clear that we are proposing this
change. I note that the document is approved by IESG and thus I like to
ensure that we still have consensus on this.

I hope that other RTP Payload format authors are paying attention to
this. The template text is fairly carefully constructed  to be clear and
not blur the lines of responsibility in this matter. The point of the
above paragraph of template is to avoid this type of discussions.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Fri, 10 Apr 2015 08:24:01 +0100

> above paragraph of template is to avoid this type of discussions.

+1 no objections

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