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

[Tom Kristensen <[e-mail]>]

On 11/04/2010 05:31 PM, Scott G. Kelly 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.

> 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).

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