Last Call Review of draft-ietf-payload-vp8-08
review-ietf-payload-vp8-08-secdir-lc-weis-2013-06-20-00

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 document describes an RTP payload specification applicable to the
transmission of video streams encoded using the VP8 video codec defined in RFC
6386. It defines how the RTP header is used, and describes the format of a VP8
payload including sender and receiver semantics.

The Security Considerations document points to the Security Considerations of
RFC 3550 (RTP), which seems appropriate since the codec fits entirely within
the RTP framework. It does specifically call out protections that should be
applied to the RTP packets, and notes that there a number of
application-specific mechanisms that can provide those protections. I just have
a couple minor comments/questions on this section.

1. Unless the SRTP recommendation in lower case was a WG consensus item I would
suggest using upper-case RECOMMENDED to better convey the importance of
protecting the RTP traffic.

2. The penultimate sentence makes a claim about the payload format being
"unlikely to pose a denial-of-service threat due to the receipt of pathological
data." I'm not sure what threat this is describing. If one is worried about a
denial-of-service threat then the packet should be integrity protected and
include a replay protection method (e.g., using SRTP). A non-key holder (e.g.,
man-in-the-middle) will not be able to create a correctly formed protected data
packet so the denial-of-service properties of the data itself should be moot.
Is there another threat here that I'm missing that makes this worth mentioning?

Brian