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

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 20 Nov 2013 07:08:06 -0700

Hi David,

Thanks for the review and sorry for the late reply - a new job and an
interstate move got in the way.

See my answer below.

On 10/17/2013 12:50 PM, ietfdbh wrote:
> Hi,
> 
> Whoops. I forgot to copy this beyond the
> draft-ietf-avtext-multiple-clock-rates@ expansion.
> 
> David Harrington [email-masked] +1-603-828-1401
> 
>> -----Original Message----- From: ietfdbh [mailto:[email-masked]] 
>> Sent: Wednesday, October 16, 2013 1:11 PM To:
>> [email-masked]' 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.

The text does not really change the way SSRC have been supposed to be used;
the text in RFC 3550 should have been interpreted as mandating different SSRC
for different clock rates.  But the fact is that most implementations were
using it wrong (i.e. using non-monotonic timestamps), so whatever the security
properties are of using non-monotonic timestamps, this draft mandates to go
back to what RFC 3550 was saying from the beginning, and so when using section
4.1, the security properties are the same than for RFC 3550.

But section 4.2 makes it legal to use the same SSRC when changing clock rates
(making RTP receivers compatible with legacy RTP senders that got RFC 3550
wrong), so the question would be:  Does using the formula in section 4.2
instead of the formula in section 3.2.2 introduce vulnerabilities when the
packet is encrypted, as the timestamp value will be influenced by changes in
the clock rate?  Note that the algorithm does not change the fact that the RTP
timestamp is initialized with a random offset.

Honestly, IANAC, so I do not know.  My intuition would be no, but intuitions
are rarely right in security, so would just adding some text saying that we do
not know be acceptable in the security section? (see proposed text below).

>> 
>> 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.
>> 

OLD TEXT:

 This document is not believed to effect the security of the RTP
 sessions described here in any way.

NEW TEXT:

 When the algorithm described in section 4.1 is used the security
 considerations described in RFC 3550 applies.

 The algorithm described in section 4.2 is new and so its security properties
 were not considered in RFC 3550.  Although the RTP timestamp is initialized
 with a random value like before, the timestamp value depends on the current
 and previous clock rates and this may or may not introduce a security
 vulnerability in the protocol.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug