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