Subject: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 4 Nov 2010 09:31:32 -0700 (PDT)

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This draft describes a new RTP payload format, extending existing RTP capabilities. Based on my limited understanding of RTP, this introduces no new security considerations.

The security considerations section starts off by saying this, but then goes on to talk about various security properties that could be added by various means. I found the text to be a little confusing, especially when it makes recommendations without detailing any particular threats.

I would suggest simplifying the security considerations. Here is the current text:

  "RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [6], and in any applicable RTP profile.  The main
   security considerations for the RTP packet carrying the RTP payload
   format defined within this document are confidentiality, integrity
   and source authenticity.  Confidentiality is achieved by encryption
   of the RTP payload.  Integrity of the RTP packets through suitable
   cryptographic integrity protection mechanism.  Cryptographic system
   may also allow the authentication of the source of the payload.  A
   suitable security mechanism for this RTP payload format should
   provide confidentiality, integrity protection and at least source
   authentication capable of determining if an RTP packet is from a
   member of the RTP session or not.

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this document may vary.  It is dependent on the
   application, the transport, and the signalling protocol employed.
   Therefore a single mechanism is not sufficient.  Usage of data origin
   authentication and data integrity protection of at least the RTP
   packet is RECOMMENDED, for example by use of the Secure Real-time
   Transport Protocol (SRTP) [12].  Other mechanisms that may be used
   are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
   TCP), but other alternatives may exist.

   Refer also to section 9 of RFC YYYY [3], as no reasons for separate
   considerations are introduced in this document."

I would suggest the following simplified text:

  "RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [6], and in any applicable RTP profile.  No additional
   security considerations are introduced by this specification."

(or something like this).

--Scott

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 05 Nov 2010 13:46:28 +0100

> The security considerations section starts off by saying this, but then goes on to talk about various security properties that could be added by various means. I found the text to be a little confu…

I can understand this conclusion. A simplification makes sense as the 
recommendations given here is described better within a security context 
in the RTP RFC and associated specifications. However, I'd like to keep 
the reference to the H.264 security considerations, with its codec 
specific details. My proposed text for the security considerations at 
bottom.

> (or something like this).

I would like to keep the reference to the security considerations 
section of RFC YYYY/RFC3984bis in, as specific H.264 threats and 
recommendations are included there. Cf.:
http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9

So, something like this should be fine:

   "RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [6], and in any applicable RTP profile. Refer also
    to section 9 of RFC YYYY [3]. No additional security
    considerations are introduced by this specification."

As a side note. One might consider altering the "template security 
considerations" section in the "How to Write an RTP Payload Format" 
draft according to the preferred security directorate/IESG policy for 
the RTP payload format specifications later on. Cf.:
http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13

-- Tom

---

From: Patrick Luthi <[email-masked]>
Date: Fri, 05 Nov 2010 19:23:43 +0100

Tom,

Your proposed text sounds good to me!

Regards,

Patrick

At 13:46 05/11/2010, Tom Kristensen wrote:
>>I have reviewed this document as part of the security directorate's 
>>ongoing effort to review all IETF documents being processed by the 
>>IESG.  These comments were written primarily for the benefit of the 
>>security area directors.  Document editors and WG chairs should 
>>treat these comments just like any other last call comments.
>>
>>This draft describes a new RTP payload format, extending existing 
>>RTP capabilities. Based on my limited understanding of RTP, this 
>>introduces no new security considerations.
>>
>>The security considerations section starts off by saying this, but 
>>then goes on to talk about various security properties that could 
>>be added by various means. I found the text to be a little 
>>confusing, especially when it makes recommendations without 
>>detailing any particular threats.
>
>I can understand this conclusion. A simplification makes sense as 
>the recommendations given here is described better within a security 
>context in the RTP RFC and associated specifications. However, I'd 
>like to keep the reference to the H.264 security considerations, 
>with its codec specific details. My proposed text for the security 
>considerations at bottom.
>
>draft according to the preferred security directorate/IESG policy 
>for the RTP payload format specifications later on. Cf.: