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 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BD561AE604; Mon, 9 Dec 2013 14:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.502
X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8mwDoP3FcSsM; Mon, 9 Dec 2013 14:24:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2EA971AE5FF; Mon, 9 Dec 2013 14:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1796; q=dns/txt; s=iport; t=1386627880; x=1387837480; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p5ISARUnOzAWhF65Nvul+6nJXHtj18gQ8t0CQqVF7D8=; b=CvbN6TY9dHeTU+0QUNS6loDe4/fohnrKgRn0CZ1L2ZGqigU1S9xGrI41 ZsGozpe/z/GsPS1ZjuoSM3c1lIISv6dFoivpwhjJwFDLHB40AQRst/yG3 9GIrgM83f7udBO6OsdjDynR8VUkBIxxjPl7NWkZe+DYHLJ8Mnea5QCTzn 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEFCplKtJV2a/2dsb2JhbABZgwc4U7kWgSwWdIIlAQEBAwE6PwULAgEIDgoeBQsyJQIEDgUbh2EGwGgXjl0zB4MggRMDmBSBMJBjgWuBPoIq
X-IronPort-AV: E=Sophos;i="4.93,860,1378857600"; d="scan'208";a="5515765"
Received: from ([]) by with ESMTP; 09 Dec 2013 22:24:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rB9MOdMK027399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 22:24:39 GMT
Received: from ([]) by ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 16:24:39 -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: AQHO9S1ySUG4BAsTeEei4eh9gjkuXA==
Date: Mon, 9 Dec 2013 22:24:38 +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 22:24:47 -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. 

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