Subject: Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 5 Dec 2013 16:56:38 +0000

Given the hum in the IETF plenary at the last IETF, I no longer think this document represents IETF consensus. Given the hum in RTCWeb working group, I doubt this represents the consensus of the RAI area either. 

I think I would be tempted to resolve this by saying for each different scenario RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be secured and for scenarios not listed such as new usages, what the requirements are. For something like SIP, having just one way to secure RTP is much better than having many ways. 

On Nov 22, 2013, at 3:07 PM, The IESG <[email-masked]> wrote:

> 
> The IESG has received a request from the Audio/Video Transport Core
> Maintenance WG (avtcore) to consider the following document:
> - 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
>   Media Security Solution'
>  <draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-12-06. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This memo discusses the problem of securing real-time multimedia
>   sessions, and explains why the Real-time Transport Protocol (RTP),
>   and the associated RTP Control Protocol (RTCP), do not mandate a
>   single media security mechanism.  Guidelines for designers and
>   reviewers of future RTP extensions are provided, to ensure that
>   appropriate security mechanisms are mandated, and that any such
>   mechanisms are specified in a manner that conforms with the RTP
>   architecture.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Roni Even" <[email-masked]>
Date: Fri, 6 Dec 2013 01:12:10 +0200

Cullen,
Let's say hypothetically that the AVTcore WG will propose and get consensus
that for RTCweb usage the security mechanism MUST use SDES for key exchange,
do you see this as a binding recommendation for RTCweb? The selection was
done by RTCweb and not by AVTcore.

The document does not say that there should be no security but says that it
is up to the usage or a for a decision. The security option document provide
the information about the different security options available and where
they are used.

Roni Even

> -----Original Message-----
> From: avt [mailto:[email-masked]] On Behalf Of Cullen Jennings
(fluffy)
> Sent: 05 December, 2013 6:57 PM
> To: [email-masked]
> Cc: [email-masked] WG
> Subject: Re: [AVTCORE] Last Call:
<draft-ietf-avt-srtp-not-mandatory-14.txt>
> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
> Media Security Solution) to Informational RFC
> 
> 
> Given the hum in the IETF plenary at the last IETF, I no longer think this
> document represents IETF consensus. Given the hum in RTCWeb working group,
> I doubt this represents the consensus of the RAI area either.
> 
> I think I would be tempted to resolve this by saying for each different
scenario
> RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be
secured and
> for scenarios not listed such as new usages, what the requirements are.
For
> something like SIP, having just one way to secure RTP is much better than
> having many ways.
> 
> 
> 
> > [email-masked] mailing lists by 2013-12-06. Exceptionally, comments may
> > be sent to [email-masked] instead. In either case, please retain the
> > Audio/Video Transport Core Maintenance [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Fri, 6 Dec 2013 11:40:18 +0000

Cullen,

> I think I would be tempted to resolve this by saying for each different scenario RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be secured and for scenarios not listed such as ne…

I'm confused about your objection, since this draft states that we need to do exactly as you propose. 

Colin

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 6 Dec 2013 07:30:40 -0800

> I'm confused about your objection, since this draft states that we need to do exactly as you propose. 

[BA] I agree with Colin.  The document is consistent with the Danvers Doctrine and more recently expressed sentiments. 
>From Section 6: 
   Given the variability of the classes of application that use
   RTP, and the variety of the currently available security mechanisms
   described in [I-D.ietf-avtcore-rtp-security-options], no one set of
   MTI security options can realistically be specified that apply to all
   classes of RTP applications.

   Documents that define an interoperable class of applications using
   RTP are subject to [RFC3365], and so need to specify MTI security
   mechanisms.  This is because such specifications do fully specify
   interoperable applications that use RTP.  Examples of such documents
   under development in the IETF at the time of this writing are the
   RTCWEB Security Architecture [I-D.ietf-rtcweb-security-arch] and the
   Real Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis].
   It is also expected that a similar document will be produced for
   voice-over-IP applications using SIP and RTP.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 9 Dec 2013 22:16:13 +0000

> done by RTCweb and not by AVTcore.

I was pushing more on the privacy / confidentiality for RTP vs the keying, so more SRTP than SDES.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 9 Dec 2013 22:24:38 +0000

This document says RTP does not need to specify a security mechanisms and that's OK. Note this document could says you must do A or B depending on the situation but it does not. It just says it is ok not to specify anything. My read of the consensus at last plenary was that the IETF had decided it was going to stop doing that. I don't care about if this draft is published as it or not as I think this draft will have zero impact to what is deployed. I do think it is worth us being consistent on what security we expect to have in RFC going forward.

All I am asking is the IESG be consistent about how they judge consensus on this and if they decide to publish it, provide some guidance on when they think it is fine to not have security and when they think it is not fine.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 14:55:16 -0800

> I was pushing more on the privacy / confidentiality for RTP vs the keying, so more SRTP than SDES.

I don't think that you get anything meaningful without tackling key
agreement.  Even then, we're not done until we've got systems in place
for doing authentication.  Good thing we're doing something about that
with WebRTC.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 9 Dec 2013 23:59:00 +0100

Cullen,

That is absolutely not the intent of the document. From the Introduction, 2nd paragraph:

   The IETF policy on Strong Security Requirements for IETF Standard
   Protocols [RFC3365] (the so-called "Danvers Doctrine") states that
   "we MUST implement strong security in all protocols to provide for
   the all too frequent day when the protocol comes into widespread use
   in the global Internet".  The security mechanisms defined for use
   with RTP allow these requirements to be met.  However, since RTP is a
   protocol framework that is suitable for a wide variety of use cases,
   there is no single security mechanism that is suitable for every
   scenario.  This memo outlines why this is the case, and discusses how
   users of RTP can meet the requirement for strong security.

You will note that last sentence "This memo...discusses how users of RTP can meet the requirement for strong security". Experience has shown that just saying "use SRTP" is not sufficient: SRTP is not suitable to secure all uses of RTP, and the keying mechanisms needed are wildly different across different use domains. The draft explains in more detail why this is the case, and makes the case that we need -- as you suggest -- drafts explaining how to secure each class of applications using RTP (telephony, WebRTC, IPTV, etc.). It doesn't actually specify security, that it true. Rather is references to draft-ietf-avtcore-rtp-security-options (also in IETF last call) which describes the available security options, and refers to the drafts that do define mandatory-to-implement security for different application domains (e.g., the WebRTC security architecture).

If some part of the draft is unclear about this, and can possibly be interpreted to allow insecure use of RTP, please explain what, and we will fix it. 

Colin

On 9 Dec 2013, at 23:24, Cullen Jennings (fluffy) <[email-masked]> wrote:
> This document says RTP does not need to specify a security mechanisms and that's OK. Note this document could says you must do A or B depending on the situation but it does not. It just says it is ok not to specify anything.
> 
> My read of the consensus at last plenary was that the IETF had decided it was going to stop doing that. I don't care about if this draft is published as it or not as I think this draft will have zero impact to what is deployed. I do think it is worth us being consistent on what security we expect to have in RFC going forward.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 15:13:16 -0800

> If some part of the draft is unclear about this, and can possibly be interpreted to allow insecure use of RTP, please explain what, and we will fix it.

Let me theorize a little: the draft name
(draft-ietf-avt-srtp-not-mandatory) might generate some false
reactions.  Thankfully, that's not going to appear in an RFC.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 9 Dec 2013 23:55:44 +0000

WebRTC is a framework. HTTP is a framework. SIP is a framework. All of these can be used in very different ways with different deployments. I don't see RTP being a somehow special relative to many other protocols the IETF develops from the point of view of not having a minimal interoperable way of securing it. 

So lets be blunt here - this document is about justifying that RTP will not have any MTI security. I will note that rtp-security-options also does not add any MTI security requirements to RTP.  I'm OK with that. All I am raising is that was  that I don't believe that has IETF consensus based on the question at the last plenary.  If you think it does, now would be a great time to outline that argument. 

Lets just keep in perspective here that what we are talking about is the protocol use for transporting people voice when the PSTN is replaced in the US and the position of this RFC, and presumable the IETF if it is published, is that the IETF is not going to mandate a way to secure this.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 9 Dec 2013 18:39:24 -0600

On 12/9/13 4:24 PM, Cullen Jennings (fluffy) wrote:
> My read of the consensus at last plenary was that the IETF had decided it was going to stop doing that.
> [...]

A poorly constructed hum taken by the IAB Chair at an IAB plenary 
meeting does not constitute IETF consensus. The IESG has not judged 
consensus on the topics brought up at that plenary.

You will note that there is an Internet Draft 
(draft-farrell-perpass-attack) currently in Last Call for Best Current 
Practice that is being discussed on the IETF list. Some of the 
discussion indicates that the IETF does not have consensus on all of the 
issues. That's being worked through now. The outcome of that Last Call 
*will* be a case of the IESG judging consensus on those topics.

If you have an opinion on the draft in Last Call, how it will affect the 
judgment on the AVT draft, and whether it needs clarification in order 
to be useful, I'm sure your input would be appreciated.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 Dec 2013 07:53:08 +0100

On 10 Dec 2013, at 00:55, Cullen Jennings (fluffy) <[email-masked]> wrote:
> WebRTC is a framework. HTTP is a framework. SIP is a framework. All of these can be used in very different ways with different deployments.

So is RTP. That is the point of writing this draft.

> I don't see RTP being a somehow special relative to many other protocols the IETF develops from the point of view of not having a minimal interoperable way of securing it. 

What would that be? SRTP does not make sense for many deployments, and even if it did, doesn't address keying.

> So lets be blunt here - this document is about justifying that RTP will not have any MTI security.

Absolutely not. It's about saying that the appropriate MTI security depends on the class of applications. What makes sense for telephony doesn't necessarily make sense for IPTV, etc.

> I will note that rtp-security-options also does not add any MTI security requirements to RTP.  

No, but it references documents that describe the MTI security for some particular scenarios where RTP is used (e.g., the WebRTC security arch). 

> I'm OK with that. All I am raising is that was  that I don't believe that has IETF consensus based on the question at the last plenary.  If you think it does, now would be a great time to outline that argument. 

I believe there is IETF consensus that RTP needs strong security. This draft discusses how to achieve that.

> Lets just keep in perspective here that what we are talking about is the protocol use for transporting people voice when the PSTN is replaced in the US and the position of this RFC, and presumable…

That's kind-of the point: RTP is not *just* the protocol that transports voice when the PSTN is replaced; it's used in a myriad of other scenarios that are outlined in the draft. If RTP were just used for telephony, this problem would be straight-forward, and we'd have a draft specifying MTI security. As RTP is used much more widely, the requirements are more complex. This draft outlines some of the issues, it doesn't claim to provide the solution to RTP security.

Again, if there is specific text in the draft that makes this unclear, let us know and we will fix this.

Colin

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 09:49:58 -0500

On Tue, Dec 10, 2013 at 1:53 AM, Colin Perkins <[email-masked]> wrote:

> > WebRTC is a framework. HTTP is a framework. SIP is a framework. All of
> these can be used in very different ways with different deployments.
>

<hat type="none"/>

I think there is a salient distinction here.  HTTP, SIP, WebRTC all
describe fairly specific patterns of interaction, onto which security
interactions can be mapped.  They also operate with very little
pre-configuration, so it makes sense to have security
configuration/negotiation tied in with the other configuration/negotiation
that the protocol is already doing.

RTP, by contrast, is essentially impotent by itself.  If I send you an RTP
packet, you have no idea how to use it unless you have engaged in some
separate, out of band negotiation mechanism.  And those negotiations can
set up all sorts of different interaction models (as discussed in the
document).  So it seems entirely sensible for the protocol that does the
negotiation/configuration to also do the security
negotiation/configuration.  It's that protocol (SIP, RTSP, etc.) that knows
the right overall interaction model that the security needs to secure.  And
that protocol is separate from RTP.

Asking for a standard RTP security model is like asking for a standard
security model for UDP -- the semantics that you want to secure are simply
not well enough defined to build a security mechanism around.

I am very much in favor of moving toward more interoperable security.  I
pushed back some on the -security-options draft because I thought it needed
to be more prescriptive ("in situation X, do Y", e.g., "for point-to-point,
use DTLS-SRTP").  I think we could standardize on a suite of mechanisms to
cover different RTP use cases.  But it's not going to be one.

--Richard

> > I don't see RTP being a somehow special relative to many other protocols
> the IETF develops from the point of view of not having a minimal
> interoperable way of securing it.
>
> Absolutely not. It's about saying that the appropriate MTI security
> depends on the class of applications. What makes sense for telephony
> doesn't necessarily make sense for IPTV, etc.
>
> No, but it references documents that describe the MTI security for some
> particular scenarios where RTP is used (e.g., the WebRTC security arch).
>
> > I'm OK with that. All I am raising is that was  that I don't believe
> that has IETF consensus based on the question at the last plenary.  If you
> think it does, now would be a great time to outline that argument.
>
> > Lets just keep in perspective here that what we are talking about is the
> protocol use for transporting people voice when the PSTN is replaced in the
> US and the position of this RFC, and presumable the IETF if it is
> published, is that the IETF is not going to mandate a way to secure this.
>
> That's kind-of the point: RTP is not *just* the protocol that transports
> voice when the PSTN is replaced; it's used in a myriad of other scenarios
> that are outlined in the draft. If RTP were just used for telephony, this
> problem would be straight-forward, and we'd have a draft specifying MTI
> security. As RTP is used much more widely, the requirements are more
> complex. This draft outlines some of the issues, it doesn't claim to
> provide the solution to RTP security.
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 10 Dec 2013 14:11:54 -0500 (EST)

> From: "Cullen Jennings (fluffy)" <[email-masked]>

> So lets be blunt here - this document is about justifying that RTP
> will not have any MTI security. I will note that
> rtp-security-options also does not add any MTI security requirements
> to RTP.

I believe that people are confusing two similar questions:

1. Is there a single mandatory-to-implement security system for *all*
   RTP uses?

2. Are all RTP uses required to specify mandatory-to-implement
   security (although different RTP use situations may mandate
   different security systems)?

As far as I can see, draft-ietf-avt-srtp-not-mandatory-14.txt says
that the answer to question 1 is "No".  As far as I can see, Cullen is
arguing that the answer to question 2 is "Yes".  These are not
contradictory positions.

There is, of course, an implementation cost if we do not mandate the
same security solution for all RTP uses.

Dale