Last Call Review of draft-ietf-avtext-multiple-clock-rates-10
review-ietf-avtext-multiple-clock-rates-10-secdir-lc-harrington-2013-10-24-00
| Request | Review of | draft-ietf-avtext-multiple-clock-rates |
|---|---|---|
| Requested revision | No specific revision (document currently at 11) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2013-10-22 | |
| Requested | 2013-10-10 | |
| Authors | Marc Petit-Huguenin , Glen Zorn | |
| I-D last updated | 2015-10-14 (Latest revision 2013-11-23) | |
| Completed reviews |
Genart IETF Last Call review of -10
by Wassim Haddad
(diff)
Secdir IETF Last Call review of -10 by David Harrington (diff) Opsdir Telechat review of -10 by Fred Baker (diff) |
|
| Assignment | Reviewer | David Harrington |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-avtext-multiple-clock-rates by Security Area Directorate Assigned | |
| Reviewed revision | 10 (document currently at 11) | |
| Result | Has issues | |
| Completed | 2013-10-24 |
review-ietf-avtext-multiple-clock-rates-10-secdir-lc-harrington-2013-10-24-00
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