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

Richard Barnes <> Tue, 10 December 2013 14:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 69EFF1AE054 for <>; Tue, 10 Dec 2013 06:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pcLNxHHQ8-r3 for <>; Tue, 10 Dec 2013 06:50:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 29A4E1AE034 for <>; Tue, 10 Dec 2013 06:50:04 -0800 (PST)
Received: by with SMTP id uy5so5276412obc.26 for <>; Tue, 10 Dec 2013 06:49:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5OFzVOfPJCEqjfVjeXc4+R0QCJ1L40WlRrPfHRL7ttM=; b=aA4B9HMQMHJ/YTwbVyWIsfZj3odulKKlthuyo0Bx0CwB/ix8N+8zvsZPTvwrJoCOYB 8h2ha4UErfuLsm20chC4AQSVreL0EB3zgY2LdwOLlNnG/y2oR1qUasMsiB1osOQb/tnn 0nMt1GMf7n7b6XQE681jVz7cxr06AN+/2iXVpRHFQLrjKqoUQTI+K5hC5oLVvFpDY3Z1 7ahIXUPxoJWDaFwo9Mc05y4ul5g5TXRNLbAMHzasSx8/VYK2rEJhgxwr043vjBPSkT8Z uc1yvdcf9heQMplaNBGWrag+ofLmBFneX9AAp4pWSAv3sz4E8m4UWeuSPn9FLqkEi+qu TsJA==
X-Gm-Message-State: ALoCoQlM0vbqW6+B9aaAh2op4YjwcV91V6oPDfZf9HnCbEQ/1N/n0X50Q8MyUt2AlbgXr25n4mOT
MIME-Version: 1.0
X-Received: by with SMTP id z4mr6320504obw.29.1386686998767; Tue, 10 Dec 2013 06:49:58 -0800 (PST)
Received: by with HTTP; Tue, 10 Dec 2013 06:49:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 10 Dec 2013 09:49:58 -0500
Message-ID: <>
From: Richard Barnes <>
To: Colin Perkins <>
Content-Type: multipart/alternative; boundary=047d7b2e4d52f9fd2c04ed2f39e0
Cc: Cullen Jennings <>, "" <>, " 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
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Dec 2013 14:50:06 -0000

On Tue, Dec 10, 2013 at 1:53 AM, Colin Perkins <> wrote:

> On 10 Dec 2013, at 00:55, Cullen Jennings (fluffy) <>
> 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.

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


> > 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 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.
> Again, if there is specific text in the draft that makes this unclear, let
> us know and we will fix this.
> Colin