Hi, Whoops. I forgot to copy this beyond the draft-ietf-avtext-multiple-clock-rates@ expansion. David Harrington ietfdbh at comcast.net +1-603-828-1401 > -----Original Message----- > From: ietfdbh [ mailto:ietfdbh at comcast.net] > Sent: Wednesday, October 16, 2013 1:11 PM > To: 'draft-ietf-avtext-multiple-clock-rates at tools.ietf.org' > 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 > ietfdbh at comcast.net > +1-603-828-1401