On Tue, Dec 10, 2013 at 1:53 AM, Colin Perkins <csp@xxxxxxxxxxxxx> wrote:
On 10 Dec 2013, at 00:55, Cullen Jennings (fluffy) <fluffy@xxxxxxxxx> wrote:So is RTP. That is the point of writing this draft.
> 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.What would that be? SRTP does not make sense for many deployments, and even if it did, doesn't address keying.
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.
> So lets be blunt here - this document is about justifying that RTP will not have any MTI security.
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 will note that rtp-security-options also does not add any MTI security requirements to RTP.
I believe there is IETF consensus that RTP needs strong security. This draft discusses how to achieve that.
> 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.
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.
> 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.
Again, if there is specific text in the draft that makes this unclear, let us know and we will fix this.
Colin