Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto
"Roni Even" <ron.even.tlv@gmail.com> Fri, 10 April 2015 08:40 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336761A033A; Fri, 10 Apr 2015 01:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfXiieRnNE-6; Fri, 10 Apr 2015 01:39:58 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27EC1A0354; Fri, 10 Apr 2015 01:39:57 -0700 (PDT)
Received: by wgsk9 with SMTP id k9so10652632wgs.3; Fri, 10 Apr 2015 01:39:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=FF2VETje45nRaZGsb6ahKiOFD4KUVLlHDiMFMu46Xoo=; b=S9ouHHclShekddxdeEmWQooEfVB4B8r4StXV6RjgI3iZ9OYQ4e+xlEvqrzsp0gT1Mp gHnhID9iDh2/anVimtTQGKrob8B8RR2B6QxGYV3VImJmTcf+IWZIqr/o2KKPRk1qOgTJ SNNxxoYoQLFNkdP/GbacXJAGwOhFvzE+o1zjaOYgkJS6IZEJwuQI1inxZfsdCFmYmyGQ SVquDpEY4JIF+fOGQuSQRB7QLLkGwixVluKDfG73MRKSYYeCdVqxTo/Kzz7hiTLE43U5 TrGuQd/h28qVW6JgQCqoYbqIRRn8v6AhgJIP15WxfTYjYbvImzpC6P6h0VNPqQZdzofT 8EVA==
X-Received: by 10.180.102.228 with SMTP id fr4mr2886478wib.4.1428655196421; Fri, 10 Apr 2015 01:39:56 -0700 (PDT)
Received: from RoniE (bzq-79-179-125-202.red.bezeqint.net. [79.179.125.202]) by mx.google.com with ESMTPSA id it5sm23786769wid.3.2015.04.10.01.39.54 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Apr 2015 01:39:55 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, payload@ietf.org
References: <55277811.70905@ericsson.com>
In-Reply-To: <55277811.70905@ericsson.com>
Date: Fri, 10 Apr 2015 11:39:49 +0300
Message-ID: <004b01d07369$e9f963a0$bdec2ae0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLJTn5m8zEOLo/nXI6nm7TcqkTanJtUNmHw
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/9_gHOLUXIEbK1gBzQlU5K64NLMg>
Cc: 'IESG' <iesg@ietf.org>
Subject: Re: [payload] Update of security template text in draft-ietf-payload-rtp-howto
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2015 08:40:00 -0000
Hi, I think this change is important and support it as individual. Roni Even > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 10 April, 2015 10:13 AM > To: payload@ietf.org > Cc: IESG > Subject: [payload] Update of security template text in draft-ietf-payload-rtp- > howto > > Payload WG and IESG, > > Due to the discussion regarding the security considerations in draft-ietf- > payload-rtp-opus it has been proposed that a small edit is performed on the > security consideration template text that discusses the role of the security > considerations for payload formats. > > "How to Write an RTP Payload Format" (draft-ietf-payload-rtp-howto) is an > approved I-D and thus I like to make this consensus call for this change before > acting on it. > > Section A.13: > > OLD: > > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] , and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" > [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload > formats responsibility to discuss or mandate what solutions are used > to meet the basic security goals like confidentiality, integrity and > source authenticity for RTP in general. This responsibility lays on > anyone using RTP in an application. They can find guidance on > available security mechanisms and important considerations in Options > for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options]. > The rest of the this security consideration discusses the security > impacting properties of the payload format itself. > > > NEW: > > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] , and in any applicable RTP profile such as > RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ > SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: > Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] > discusses it is not an RTP payload formats responsibility to discuss > or mandate what solutions are used to meet the basic security goals > like confidentiality, integrity and source authenticity for RTP in > general. This responsibility lays on anyone using RTP in an > application. They can find guidance on available security mechanisms > and important considerations in Options for Securing RTP Sessions > [RFC7201]. Applications SHOULD use one or more appropriate strong > security mechanisms. The rest of the this security consideration > discusses the security impacting properties of the payload format > itself. > > Change is the new second to last sentence, and updated references. > > If no objections are heard in 2 weeks time, by the 25th of April 2015, I will > submit a new version with this change. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload
- [payload] Update of security template text in dra… Magnus Westerlund
- Re: [payload] Update of security template text in… Kathleen Moriarty
- Re: [payload] Update of security template text in… Magnus Westerlund
- Re: [payload] Update of security template text in… Ross Finlayson
- Re: [payload] Update of security template text in… Roni Even