Subject: Fwd: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long)

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Sep 2004 17:37:20 +0100

Elisabetta,

Just made the mistake of sending before reading (I just read your 31 Aug 04 
posting on msec)...

You make it clear that the RTP timestamp isn't as reliable as I thought. Is 
this possible by design, or just due to some crap implementations?

So, I guess the advice should be to add a key index field unless the 
implementor is sure of the reliability of the RTP timestamp. If this 
assurance is going to be rare, it's a good argument for not allowing any 
option, and always mandating the addition of a key index field...

...However, I'm wary of forcing 32 redundant bits per packet just because 
another code module is often flakey. THat's more an argument for fixing the 
flakey code, not adding bloat to allow for flakiness elsewhere. It's not 
unreasonable to expect that adding time-dependent security to an RTP 
implementation will require tightening up pre-existing timestamping code.

Of course, there might be a problem if you don't have access to someone 
else's RTP source that you depend on. But is this really a likely scenario?

Bob

>Date: Tue, 14 Sep 2004 17:12:47 +0100
>To: canetti <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Re: [MSEC] Review of draft-ietf-msec-srtp-tesla-01.txt (long)
>Cc: Mark Baugher <[email-masked]>, [email-masked]
>Bcc: ƒ\Charging\Security\IN msec
>
>Ran,
>
>At 05:14 31/08/2004, canetti wrote:
>>2. I think that Bob's idea of having the receiver infer the interval
>>number from the RTP timestamp may work in some/many cases. But it might
>>make the programming more delicate and harder to get right. One potential
>>solution is just to opt for a more robust design at the price of extra 4
>>bytes p.p. altenratively, we can make  the interval number optional and
>>leave it up to the implementation whether it wants to save the extra 4
>>bytes or not.
>
>1/ It's really not delicate or hard...
>
>Just like when on reception, the earliest slot the sender can be in is 
>computed based on packet arrival time, t_j (in TESLA-intro section 3.5):
>         floor[(t_j - T_0)/T_int = K_i]
>
>The slot K_s that the sender appears to have been in when it sent the 
>packet can be computed based on RTP timestamp, t_s:
>         floor[(t_s - T_0)/T_int = K_s]
>
>If there's significant delay in the sender stack after the RTP timestamp 
>is applied, that doesn't change the security; it can just all be put down 
>as extra network delay (but avoidable by more careful implementation).
>
>2/ Just to emphasise a point that Adrian Perrig reminded me of when we met 
>(offline) recently....
>
>This use of the RTP timestamp (just like use of the key index) must not be 
>assumed to say anything authentic about the time the packet was sent until 
>after the packet is authenticated. It is merely a hint as to which key to 
>try in order to see whether the packet is authentic. Then, only if the key 
>the timestamps hints at does indeed create a matching MAC to that in the 
>packet, can one say that the timestamp (or key index) was indeed 
>authentic. This is implicit authentication - because correct 
>authentication depended on it.
>
>So, we must still have the timeslot plan for the whole key chain signed in 
>advance under an asymmetric key. The timestamps or key indices in the 
>packets are NOT authentic until proven so by implicit authentication.
>
>
>Bob
>
>____________________________________________________________________________
>Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      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: Tue, 14 Sep 2004 10:04:31 -0700

hi Bob
On Sep 14, 2004, at 9:37 AM, Bob Briscoe wrote:

> Elisabetta,
>
> Just made the mistake of sending before reading (I just read your 31  
> Aug 04 posting on msec)...
>
> You make it clear that the RTP timestamp isn't as reliable as I  
> thought. Is this possible by design, or just due to some crap  
> implementations?

It's by design, I believe:  If the timestamp is the presentation  
timestamp as in some MPEG types and a group of packets make up one  
presentation unit, then they will all have the same timestamp.

Mark
> assurance is going to be rare, it's a good argument for not allowing  
> any option, and always mandating the addition of a key index field...
>
> ...However, I'm wary of forcing 32 redundant bits per packet just  
> because another code module is often flakey. THat's more an argument  
> for fixing the flakey code, not adding bloat to allow for flakiness  
> elsewhere. It's not unreasonable to expect that adding time-dependent  
> security to an RTP implementation will require tightening up  
> pre-existing timestamping code.
>
> Of course, there might be a problem if you don't have access to  
> someone else's RTP source that you depend on. But is this really a  
> likely scenario?
>
>
> Bob
>
>
>> Just like when on reception, the earliest slot the sender can be in  
>> is computed based on packet arrival time, t_j (in TESLA-intro section  
>> 3.5):
>> If there's significant delay in the sender stack after the RTP  
>> timestamp is applied, that doesn't change the security; it can just  
>> all be put down as extra network delay (but avoidable by more careful  
>> implementation).
>>
>> 2/ Just to emphasise a point that Adrian Perrig reminded me of when  
>> we met (offline) recently....
>>
>> This use of the RTP timestamp (just like use of the key index) must  
>> not be assumed to say anything authentic about the time the packet  
>> was sent until after the packet is authenticated. It is merely a hint  
>> as to which key to try in order to see whether the packet is  
>> authentic. Then, only if the key the timestamps hints at does indeed  
>> create a matching MAC to that in the packet, can one say that the  
>> timestamp (or key index) was indeed authentic. This is implicit  
>> authentication - because correct authentication depended on it.
>>
>> So, we must still have the timeslot plan for the whole key chain  
>> signed in advance under an asymmetric key. The timestamps or key  
>> indices in the packets are NOT authentic until proven so by implicit  
>> authentication.
>>
>>
>> Bob
>>

---

From: "David A. McGrew" <[email-masked]>
Date: Tue, 14 Sep 2004 10:06:00 -0700

Bob,

> thought. Is this possible by design, or just due to some crap  

The non-regularity of the RTP timestamp is not just due to bad  
implementations.
 From the RTP FAQ maintained by Henning Schulzrinne  
(http://www.cs.columbia.edu/~hgs/rtp/faq.html#timestamp-seqno):

<quote>
What are the roles of the RTP timestamp and sequence numbers?

The timestamp is used to place the incoming audio and video packets in  
the correct timing order (playout delay compensation). The sequence  
number is mainly used to detect losses. Sequence numbers increase by  
one for each RTP packet transmitted, timestamps increase by the time  
"covered" by a packet. For video formats where a video frame is split  
across several RTP packets, several packets may have the same  
timestamp. In some cases such as carrying DTMF (touch tone) data (RFC  
2833), RTP timestamps may not be monotonic.
</quote>

We also have to consider that there may be codec changes during a  
single TESLA flow, in which case the timestamp might change from one  
monotonic sequence to another, thus disrupting TESLA if it relied on  
the RTP codec.

In my experience with SRTP, it is best to make as few assumptions about  
the RTP fields as possible.  It would be better for SRTP TESLA to not  
re-use the RTP timestamp, in my opinion, because that will better  
enable the protocol to be used with existing RTP systems without any  
security concern.  I regret the loss of four bytes packet for a  
TESLA-specific timestamp, but I would prefer to have a protocol that we  
could recommend without qualifications.

David

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Sep 2004 19:24:54 +0100

David, Mark,

>could recommend without qualifications.

Tx for both your explanations, which make it all much clearer why it's more 
complicated. I've scanned the refs you gave and now I know how much I don't 
know. Although you all seem to know a fair bit about this and have a good 
deal of experience, may I be so bold as to say that I detect there is an 
element of assuming there might be a problem, rather than strictly 
analysing whether there really is a problem. This is relevant to whether we 
make a key index field MANDATORY or OPTIONAL. I'm just wary of adding bloat 
to a protocol because no-one can work out (without a lot of work) whether 
it is needed or not.

If the key index were derived from the RTP timestamp:

i) TESLA security would depend absolutely on the RTP timestamp not stating 
a time AFTER the packet had been sent.
I can't see a case where this might happen. Is there?

ii) Also TESLA performance would depend on the RTP timestamp not stating a 
time too far (x) prior to sending (eg when a video frame is split into 
multiple packets).
If (network_delay + x) still allowed a workable authentication delay, there 
might not be a performance problem.

It seems that the various timestamp bases can all be recalculated back to 
wallclock time. So changing codecs, etc should all be OK. But, I have a 
great deal of uncertainty over that statement.

At first sight, PSTN gateways seem a problem: converting DTMF tones in the 
audio to a new stream of telephony event media packets. Clearly, these 
would be timestamped after they left the original sender. But, of course, 
being new payloads, these would have to be authenticated by the gateway, 
not the sender. Requiring each TESLA receiver to time synch with the 
gateway as another source. Arrrgghh - the complications of legacy... ...but 
importantly these are complications, not protocol failures.

Do you get my drift? THe real question is:
- MANDATORY key index because we're sure dependence on the RTP timestamp 
will cause security or performance failures in ALL cases (or such a large 
majory of cases that having an option would cause unnecessary complication)
- OPTIONAL key index, because we think it might cause problems, but no-one 
can be bothered to work it all out to see whether there will be a 
significant number of cases that CAN safely rely on the RTP timestamp.

Bob

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 15 Sep 2004 09:08:42 -0700

Bob,

On Sep 14, 2004, at 11:24 AM, Bob Briscoe wrote:

> Tx for both your explanations, which make it all much clearer why it's  
> more complicated. I've scanned the refs you gave and now I know how  
> much I don't know. Although you all seem to know a fair bit about this  
> and have a good deal of experience, may I be so bold as to say that I  
> detect there is an element of assuming there might be a problem,  
> rather than strictly analysing whether there really is a problem.

No, that is not the case.  I favor making the security of SRTP TESLA  
independent of the use of the RTP timestamp so that protocol will be  
resilient against different usages of RTP.

Here is an example of a use of RTP that will break when used with your  
proposal.  Define the 'short message' codec as one that passes short  
ASCII strings in the RTP payload, with a timestamp that starts at zero  
and is monotonically increasing.  The receiver is expected to display  
these messages in order, e.g. on a display panel.  Now interleave the  
use of this code with an audio codec over the same SSRC, using the  
Payload Type field in the RTP header to indicate which codec is in  
effect for each packet.  (Example application: pass URLs or phone  
numbers during a presentation.)  The timestamp is set by the codec, and  
every time that the payload type switches to the 'short message' codec,  
the timestamp jumps to zero again.

It can be debated whether or not the RTP usage that I described is  
legal w.r.t. the specifications, since the SSRC did not change when the  
codec changed (which is the preferred behavior).  However, this sort of  
RTP usage *does* occur in practice, so its conformance with the  
specifications is a moot point.

David

> This is relevant to whether we make a key index field MANDATORY or  
> OPTIONAL. I'm just wary of adding bloat to a protocol because no-one  
> can work out (without a lot of work) whether it is needed or not.
>
> i) TESLA security would depend absolutely on the RTP timestamp not  
> stating a time AFTER the packet had been sent.
> ii) Also TESLA performance would depend on the RTP timestamp not  
> stating a time too far (x) prior to sending (eg when a video frame is  
> split into multiple packets).
> If (network_delay + x) still allowed a workable authentication delay,  
> there might not be a performance problem.
>
> It seems that the various timestamp bases can all be recalculated back  
> to wallclock time. So changing codecs, etc should all be OK. But, I  
> have a great deal of uncertainty over that statement.
>
> At first sight, PSTN gateways seem a problem: converting DTMF tones in  
> the audio to a new stream of telephony event media packets. Clearly,  
> these would be timestamped after they left the original sender. But,  
> of course, being new payloads, these would have to be authenticated by  
> the gateway, not the sender. Requiring each TESLA receiver to time  
> synch with the gateway as another source. Arrrgghh - the complications  
> of legacy... ...but importantly these are complications, not protocol  
> failures.
>
> - MANDATORY key index because we're sure dependence on the RTP  
> timestamp will cause security or performance failures in ALL cases (or  
> such a large majory of cases that having an option would cause  
> unnecessary complication)
> - OPTIONAL key index, because we think it might cause problems, but  
> no-one can be bothered to work it all out to see whether there will be  
> a significant number of cases that CAN safely rely on the RTP  
> timestamp.
>
>
>
> Bob
>
>