Subject: [payload] Update of security template text in draft-ietf-payload-rtp-howto

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Apr 2015 09:13:21 +0200

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: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Fri, 10 Apr 2015 11:39:49 +0300

Hi,
I think this change is important and support it as individual.

Roni Even

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 10 April, 2015 10:13 AM
> To: [email-masked]
> 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:
> 
> 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
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 10 Apr 2015 02:10:53 -0700

>   discusses it is not an RTP payload formats responsibility to discuss

Add a comma after “discusses’.  Also: “formats” -> “format’s”

>   discusses the security impacting properties of the payload format

    Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Apr 2015 13:16:21 +0200

Thanks,

will happily apply this editorial fixes.

/Magnus

-- 

Magnus Westerlund

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 10 Apr 2015 08:47:50 -0400

Thank you, Magnus.

I think the new text represents the current considerations well.  The recommendation to use one or more strong security mechanism works for me.

Best regards,
Kathleen 

Sent from my iPhone

> On Apr 10, 2015, at 7:16 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Thanks,
>