Skip to main content

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