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

"Cullen Jennings (fluffy)" <> Mon, 09 December 2013 23:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D3B21ADF97; Mon, 9 Dec 2013 15:56:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -114.502
X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oAt3ByMX-0j0; Mon, 9 Dec 2013 15:56:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EAEE41ADF6D; Mon, 9 Dec 2013 15:56:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5221; q=dns/txt; s=iport; t=1386633358; x=1387842958; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OxLpFomaFtG3wpM4vDpd3JMQXMmZ3K5wuvvP22nW1yo=; b=b7j7CShNGaFACZlf6xCC1Zv6sxMRQbq7rmgfZ6wcB1PaS/oCwa8IHbxw RaJZ0Ru+EG99Gn/H7sCoe8VA9pES/4fmgip3/Tz/I++3L7/jGzGBsQbJ4 0eTH4pE7peEuyfinPEdrbKFwM9OQfgkneNFPsVXdWWTDIiV4mFAV+N+N7 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,861,1378857600"; d="scan'208";a="290257334"
Received: from ([]) by with ESMTP; 09 Dec 2013 23:55:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rB9NtjVM022093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 23:55:45 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 17:55:45 -0600
From: "Cullen Jennings (fluffy)" <>
To: Colin Perkins <>
Thread-Topic: [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
Thread-Index: AQHO9TI/4zL5yzK36kiDXTnTRhbU4JpM7oiA
Date: Mon, 09 Dec 2013 23:55:44 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, " 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: Mon, 09 Dec 2013 23:56:09 -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. 


On Dec 9, 2013, at 3:59 PM, Colin Perkins <>

> 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) <> 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.
>> 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. 
>> On Dec 6, 2013, at 4:40 AM, Colin Perkins <> wrote:
>>> Cullen,
>>> On 5 Dec 2013, at 16:56, Cullen Jennings (fluffy) <> wrote:
>>>> 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. 
>>> I'm confused about your objection, since this draft states that we need to do exactly as you propose. 
>>> Colin
>>> -- 
>>> Colin Perkins
>> _______________________________________________
>> Audio/Video Transport Core Maintenance