Subject: [MSEC] Key index field is redundant with SRTP

From: Bob Briscoe <[email-masked]>
Date: Thu, 02 Sep 2004 09:15:19 +0100

Mark,

This is issue 1/ split out from the long thread reviewing 
draft-ietf-msec-srtp-tesla-01.txt

more inline...

>>>>The key index can be derived from the RTP timestamp in each message.
>>>>This saves 4 bytes in each packet.
>>>
>>>I would not say that two fields are redundant if they perform different
>>>functions, which I think is the case here.  We would need to do a
>>>complete analysis of how the timestamp is used today in RTP
>>>applications before we can evaluate how safe this would be for all
>>>applications.  I'd prefer to not overload an existing field in this way
>>>if we can avoid it.
>>
>>I had thought about the ramifications fairly carefully before saying
>>this. I suggest that the way to deal with the TESLA time interval
>>identifier, I, is to:
>>- remove I from the default TESLA-SRTP packet format
>>- explain how to derive I from the RTP timestamp
>
>I may have confused you in my last note in trying to explain all the
>ways that I think overloading protocol fields for security purposes is
>generally not a good idea.  Let me try to state this clearly: The RTP
>timestamp is used for specific purposes for RTP payload types that are
>unrelated to sender authentication, and it is quite possible that we
>will either interfere with these uses by placing TESLA-induced
>constraints on that field or weaken TESLA security when we find
>surprising uses are made of that field by certain applications.
>
>Re-use of the RTP Timestamp in TESLA can be easily avoided by adding a
>TESLA timetamp field in the packet.  I think the points you are raising
>are important and helpful to SRTP-TESLA.  But it would helpful if you
>separated them I think.
>Re-use of the RTP timestamp, the non-mandatory
>group MAC, and your proposal under point 3 can stand by themselves.  I
>think we have 3 threads here and not one.
>
>>- MANDATE that a sender authentication module should use a TESLA key
>>interval derived from the RTP timestamp, not the clock
>>- warn implementors that any delay in the sender stack will add to the
>>TESLA authentication delay (but not weaken it)
>>- (if we can think of any other problems ) warn implementors what to
>>watch out for when overloading the RTP timestamp function (I'm fairly
>>sure there aren't any - and I've thought long and hard)
>
>I'd prefer to use a separate field.  At minimum, I would take this to
>AVT for further discussion.  I don't think the gain from overloading is
>worth any unexpected pitfalls, particularly security pitfalls.  RTP is
>a special beast because it is used in so many types of applications,
>from telephony to client/server multimedia, from unicast-pairwise to
>unicast-group, small multicast conferences to large-scale broadcast,
>etc.

Certainly put it to AVT.

>>- make I optional in the TESLA-SRTP packet format for implementors to
>>use if they are in one of these obscure scenarios

...despite what I said above, I wholly support trying to avoid options. 
Perhaps if someone comes up with an odd use of the RTP timestamp, it's up 
to them to work round the standard by changing the layering in their 
implementation. I'd rather we don't add more packet size for hypothetical 
odd uses of the timestamp, unless someone comes up with a concrete one they 
can't work round.

>>>>If the sender buffers packets between adding the RTP timestamp and
>>>>adding TESLA authentication fields, this will add to the TESLA
>>>>authentication delay. But a good RTP implementation shouldn't be
>>>>doing
>>>>serious buffering here.
>>>
>>>What about high-bandwidth, server/playback media such as movies?  In
>>>fact, let me try this:  What about an MPEG packetizer that does a lot
>>>of pre-processing of the MPEG AUs prior to assigning them to packets.
>>>This might happen because the AUs were encrypted and required a lot of
>>>pre-processing.  Maybe there would be a two-step process applied to
>>>one
>>>or more AUs in which timetamps are assigned during some processing and
>>>then everything gets sent.
>>>Maybe such a problem can be avoided in packetizers.  There are a lot
>>>of
>>>considerations when we take an existing field such as the RTP
>>>timestamp
>>>and add new functions to it.
>>
>>As long as we mandate that the TESLA sender uses the key appropriate
>>to the time interval derived from the RTP timestamp (not from the
>>clock), the protocol is safe. The TESLA safety test is still accurate.
>>
>>Any delay after RTP has determined its timestamp then folds into the
>>delay between sender and receiver that TESLA is designed to handle
>>safely. Of course, this makes the delay longer, which /delays/
>>authentication. But it doesn't /weaken/ authentication. See section 4
>>of the TESLA intro for discussion of similar scenarios (eg TCP
>>buffering).
>>
>>If authentication delay is a problem for a particular scenario, and
>>it's some odd scenario like you suggest where a large part of the
>>delay is within the sender stack between RTP and TESLA, then the
>>implementor can choose to use an explicit I in the packet.
>
>TESLA is complex enough without adding protocol dependencies like this
>in my view.
>
>>
>>>If the functions are really identical, then they are redundant.  I
>>>tend
>>>to doubt that.
>>
>>I'd rather say that the functions of the two fields are invariably
>>equivalent, but may not be in some scenarios, when it's up to the
>>implementor to use the option of an explicit I.
>
>This new option will double the signaling, implementation, testing, and
>operational complexity of the protocol.

Understood

Cheers

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196 

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Sun, 12 Sep 2004 15:52:27 -0700

hi Bob,
   Do you still think we should use the RTP timestamp in place of the  
key ID?

Mark
On Sep 2, 2004, at 1:15 AM, Bob Briscoe wrote:

> ...despite what I said above, I wholly support trying to avoid  
> options. Perhaps if someone comes up with an odd use of the RTP  
> timestamp, it's up to them to work round the standard by changing the  
> layering in their implementation. I'd rather we don't add more packet  
> size for hypothetical odd uses of the timestamp, unless someone comes  
> up with a concrete one they can't work round.
>
>
> Notice: This contribution is the personal view of the author and does  
> not necessarily reflect the technical nor commercial direction of BT  
> plc.