[secdir] FW: secdir review of draft-ietf-avtext-multiple-clock-rates-10

["ietfdbh" <[e-mail]>]

Hi,

Whoops.
I forgot to copy this beyond the draft-ietf-avtext-multiple-clock-rates@
expansion.

David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: ietfdbh [mailto:[e-mail]]
> Sent: Wednesday, October 16, 2013 1:11 PM
> To: '[e-mail]'
> Subject: secdir review of draft-ietf-avtext-multiple-clock-rates-10
> 
> Hi,
> 
> 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 clarifies the RTP specification when different clock
>    rates are used in an RTP session.  It also provides guidance on how
>    to interoperate with legacy RTP implementations that use multiple
>    clock rates.  It updates RFC 3550.
> 
> The security considerations section says " This document is not believed
to
> effect the security of the RTP
>    sessions described here in any way."
> 
> I have a concern.
> 
> RFC3550 section 9.1 describes an encryption approach, and discusses the
> weakness of the encryption method because of poor randomness of
> timestamp offsets, and the potential for manipulation of the SSRC.
> 
> Section 4 of the current document changes how SSRCs should be (must be)
> manipulated for different scenarios, and recommends, but does not require,
> different SSRCs for each clock rate.  It also modifies how timestamps are
> calculated.
> 
> Since timestamps and SSRC manipulation are weaknesses of the encryption
> approach in RFC 3550, section 9.1, I would expect more discussion of the
> potential impact, or non-impact, of these changes to SSRCs and timestamps
> vis-à-vis the encryption strength.
> 
> David Harrington
> [e-mail]
> [phone]