Subject: [AVT] question on draft-mattsson-srtp-store-and-forward-00.txt

From: David McGrew <[email-masked]>
Date: Mon, 28 Jul 2008 12:20:39 -0700

Hello,

Section 3.2.1 says that "The answering machine, acting as a streaming  
server when sending the data to the callee, will not use the exact  
same RTP headers on the outgoing SRTP traffic as was used on the  
incoming SRTP traffic. SRTP as specified in [RFC3711] will not work in  
this case, since parts of the RTP header is input to the encryption/ 
authentication transforms."

However, some parts of the RTP header would need to be stored along  
with the payloads.  Since the answering machine is storing ciphertext  
payloads in this case, it would need to store and play back the RTP  
timestamp field, since otherwise the answering machine could not  
effectively determine what values to put into this field.  The same  
considerations would probably apply to the PT field.

Since some parts of the header necessarily need to be stored as part  
of the solution, why not store the entire header, then replay the SRTP  
session from the answering machine exactly as it was sent to it?    
This is a simple solution that avoids the need for RTP endpoints to  
implement new SRTP transforms and options.  It can be implemented by  
the answering machine's RTP/SRTP stack, without any effect on  
signaling or any need for explicit support in any other RTP/SRTP stack.

best regards,

David

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Jul 2008 00:48:44 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David McGrew
> Sent: Monday, July 28, 2008 8:21 PM
> To: [email-masked]; 
> [email-masked]; [email-masked]; Rolf 
> Blom J (KI/EAB); "Mats Näslund (KI/EAB)"; Karl Norrman ((KI/EAB))
> Cc: AVT
> Subject: [AVT] question on 
> draft-mattsson-srtp-store-and-forward-00.txt
> 
> Hello,
> 

A technical similar to that was described in Section 3.4 of
draft-wing-avt-dtls-srtp-key-transport-01
<http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-01#section-
3.4>, but I pulled it in the most recent version because in Philadelphia Dave
Oran pointed out that SPEECHSC found that such audio storage didn't work well
(for RTP), and thus would not work well for SRTP.  I am curious if
draft-mattsson-srtp-store-and-forward uncovered a new solution that doesn't
bump into the problems SPEECHSC found (but I wasn't curious enough to ask at
the microphone today).

-d

---

From: Rolf Blom J <[email-masked]>
Date: Tue, 29 Jul 2008 12:35:13 +0200

Hello,

We see 2 main reasons why it is not possible to use simple retransmission of an 
SRTP stream in a general Store & Forward scenario.

1) Using simple retransmission of the SRTP stream would only give end-to-end 
protection but no transport protection (hop-by-hop and would thus comply with 
the assumed trust model.b

2) It would not be possible to perform playback functions like rewind and fast 
forward (random seek operations). As we understand this is the reason for the 
changes in the draft-wing-avt-dtls-srtp-key-transport-02 (removal of similar 
technique).

/Rolf and John

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: den 29 juli 2008 01:49
To: 'David McGrew'; John Mattsson; Fredrik Lindholm; Yi Cheng; Rolf Blom J; Mats 
Näslund; Karl Norrman
Cc: 'AVT'
Subject: RE: [AVT] question on draft-mattsson-srtp-store-and-forward-00.txt

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> David McGrew
> [email-masked]; [email-masked]; Rolf Blom J 
> (KI/EAB); "Mats Näslund (KI/EAB)"; Karl Norrman ((KI/EAB))
> Cc: AVT

A technical similar to that was described in Section 3.4 of
draft-wing-avt-dtls-srtp-key-transport-01
<http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-transport-01#section-
3.4>, but I pulled it in the most recent version because in Philadelphia Dave 
Oran pointed out that SPEECHSC found that such audio storage didn't work well 
(for RTP), and thus would not work well for SRTP.  I am curious if 
draft-mattsson-srtp-store-and-forward uncovered a new solution that doesn't bump 
into the problems SPEECHSC found (but I wasn't curious enough to ask at the 
microphone today).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Jul 2008 13:13:28 +0100

> From: Rolf Blom J [mailto:[email-masked]] 
> Sent: Tuesday, July 29, 2008 11:09 AM
> To: Dan Wing; David McGrew
> Cc: AVT
> Subject: RE: [AVT] question on 
> We see 2 main reasons why it is not possible to use simple 
> retransmission of an SRTP stream in a general Store & Forward 
> scenario. 
> 
> 1) Using simple retransmission of the SRTP stream would only 
> give end-to-end protection but no transport protection 
> (hop-by-hop and would thus comply with the assumed trust model.b
>
> 2) It would not be possible to perform playback functions 
> like rewind and fast forward (random seek operations). As we 
> understand this is the reason for the changes in the 
> draft-wing-avt-dtls-srtp-key-transport-02 (removal of similar 
> technique).

draft-mattsson-srtp-store-and-forward says that the fast forward 
/ rewind difficulty is resolved by allowing the storage device
(voicemail server) to re-construct the SRTP header.

I'll let Dave Oran (who co-chairs SPEECHSC) why SPEECSH found
a problem with storing and forwarding RTP.  However, it is my 
understanding that SPEECSH found the problem with *RTP*.  If
my understanding is correct, the proposal in 
draft-mattsson-srtp-store-and-forward would suffer the same
fate -- because the problem is with RTP (not SRTP).

-d

> To: 'David McGrew'; John Mattsson; Fredrik Lindholm; Yi 
> Cheng; Rolf Blom J; Mats Näslund; Karl Norrman
> Cc: 'AVT'
> Subject: RE: [AVT] question on 
> Behalf Of 
> 3.4>, but I pulled it in the most recent version because in 
> Philadelphia Dave Oran pointed out that SPEECHSC found that 
> such audio storage didn't work well (for RTP), and thus would 
> not work well for SRTP.  I am curious if 
> draft-mattsson-srtp-store-and-forward uncovered a new 
> solution that doesn't bump into the problems SPEECHSC found 
> (but I wasn't curious enough to ask at the microphone today).
> 
> -d
>

---

From: David R Oran <[email-masked]>
Date: Tue, 29 Jul 2008 08:26:49 -0400

> fate -- because the problem is with RTP (not SRTP).
The problem is partly that the speechsc formulation of the stored  
media playback problem is that the playback is in fact not the un- 
transformed stored audio/video. With speechsc you can do pitch- 
preserving speedup/slowdown, skipping to arbitrary points in the  
media, etc., all of which would break both the pre-packetization  
constraints of how media is put into back into RTP ater storage, and  
the security properties of SRTP (e.g. deletion, modification, etc.).

There has been some research work done on cryptographic transforms  
that survive such manipulations, but they are still at the research  
stage, and are most definitely not of a form that would just slide  
into SRTP.

This makes any content privacy and integrity properties have to be  
independent of the transport privacy and integrity properties.

A second consideration is that it is often required that the storage  
system perform transcoding prior to storage (to save capacity), or  
transcoding on playout (to deal with playback clients not supporting  
the sender's codec). Both of these will negate the utility of this  
scheme.

Given that system builders need to deal with the general case for both  
transport, storage, playout, and security, having this capability in  
the mix this seems to not help much, if at all

There may be other use cases for which this draft might be a good  
solution, but voicemail/videomail storage and playback isn't one of  
them.

Cheers, DaveO.

---

From: Randell Jesup <[email-masked]>
Date: Tue, 29 Jul 2008 11:56:35 -0400

David McGrew <[email-masked]> writes:
>server when sending the data to the callee, will not use the exact  same
>RTP headers on the outgoing SRTP traffic as was used on the  incoming SRTP
>traffic. SRTP as specified in [RFC3711] will not work in  this case, since
>parts of the RTP header is input to the encryption/ authentication
>transforms."
>
>However, some parts of the RTP header would need to be stored along  with
>the payloads.  Since the answering machine is storing ciphertext  payloads
>in this case, it would need to store and play back the RTP  timestamp
>field, since otherwise the answering machine could not  effectively
>determine what values to put into this field.  The same  considerations
>would probably apply to the PT field.

>Since some parts of the header necessarily need to be stored as part  of
>the solution, why not store the entire header, then replay the SRTP
>session from the answering machine exactly as it was sent to it?    This is
>a simple solution that avoids the need for RTP endpoints to  implement new
>SRTP transforms and options.  It can be implemented by  the answering
>machine's RTP/SRTP stack, without any effect on  signaling or any need for
>explicit support in any other RTP/SRTP stack.

This is quite problematic for RTP:

1) If you replay headers, you are simulating another source (ssrc).  While
   in theory the receiver should handle a different timestamp base and set
   of sequence numbers for a different source (practice might be another
   question... and what it does when it sees a new source - it might well
   just ignore the new stream), if there's an SSRC collision there's no way
   to respond to it.
2) No action other than real-time replay is possible - no FF/REW/skip/etc.
3) Big problem - the PT you send has to be the PT that the *other* side
   said it wanted for the codec (not to mention the offer/answer
   parameters).  If they sent an INVITE (or OK) with PT 99 being iLBC, and
   your stored message has 98 as iLBC, you're screwed.  If you stick to
   "static" codecs (especially PCMU/A), it's easier - modulo things like
   support for silence suppression, etc.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: David McGrew <[email-masked]>
Date: Tue, 29 Jul 2008 17:26:45 -0700

Hi Dave,

> stage, and are most definitely not of a form that would just slide  

I'd go further and suggest that any privacy homomorphism that could  
perform manipulations such as speedup/slowdown would not actually be  
able to meet a satisfactory definition of security.

David

> Given that system builders need to deal with the general case for  
> both transport, storage, playout, and security, having this  
> capability in the mix this seems to not help much, if at all
>

---

From: Rolf Blom J <[email-masked]>
Date: Wed, 30 Jul 2008 12:26:08 +0200

Hi,

Thanks for all your comments. They really highlight the problems we
have seen when we tried to design our solution for end-to-end security
combined with hop-by-hop security in a store and forward application.

We want to point out that the voice mail application is just one
example application but we use it because it exhibits many of the
problems encountered  including those that you have pointed ourt. Thus
it is an excellent starting point for deriving requirements. If we can
design a solution fulfilling those requirements we believe that all
important store and forward applications would also be covered. In the
next version of the draft we will expand on these other applications.

We also want to make it clear that SRTP Store and Forward is intended
for services where end-to-end security is the driving requirement. This
means that users would be willing/have to abstain from services relying
on the availability of plaintext, e.g for trancoding, speed-up,
slow-down, etc. However, skipping in the media stream and other random
seek functions would be possible with the proposed solution.

It will of course be necessary to have a hint track associated with the
recorded encrypted media which would be used when retransmitting it.
We did not mention the need for the hint track as we wanted to focus on
the pure security and SRTP issues.

In the solution sketch the media payload is encrypted independently of
the transport (RTP headers), and thus fulfills exactly the requirement
stated by David Oran ("This makes any content privacy and
integrity properties have to be
independent of the transport privacy and integrity properties")  When protected media is forwarded with hop-by-hop
protection a new and independent RTP/SRTP session will be initiated.

Rolf and John

David McGrew wrote:

Hi Dave,

-----Original Message-----

Cc: AVT

Hello,

scenario.

technique).

The problem is partly that the speechsc formulation of the stored media
playback problem is that the playback is in fact not the un-transformed
stored audio/video. With speechsc you can do pitch-preserving
speedup/slowdown, skipping to arbitrary points in the media, etc., all
of which would break both the pre-packetization constraints of how
media is put into back into RTP ater storage, and the security
properties of SRTP (e.g. deletion, modification, etc.).

There has been some research work done on cryptographic transforms that
survive such manipulations, but they are still at the research stage,
and are most definitely not of a form that would just slide into SRTP.

David

This makes any content privacy and integrity
properties have to be independent of the transport privacy and
integrity properties.

Cheers, DaveO.

-d

/Rolf and John

-----Original Message-----

Cc: 'AVT'

-----Original Message-----

Behalf Of

David McGrew

Cc: AVT

Hello,

Section 3.2.1 says that "The answering machine, acting as a

streaming

server when sending the data to the
callee, will not use the exact

incoming SRTP traffic. SRTP as specified in [RFC3711] will

not work in

this case, since parts of the RTP
header is input to the

encryption/

with the payloads.  Since the answering machine is storing

ciphertext

payloads in this case, it would need to
store and play back the RTP

Since some parts of the header necessarily need to be

stored as part

of the solution, why not store the
entire header, then

replay the SRTP

session from the answering machine
exactly as it was sent to it?

implement new SRTP transforms and options.  It can be

implemented by

the answering machine's RTP/SRTP stack,
without any effect on

signaling or any need for explicit support in any other RTP/SRTP

stack.

<http://tools.ietf.org/html/draft-wing-avt-dtls-srtp-key-trans

port-01#section-

-d

--
Rolf Blom, Ph.D. Expert, Mobile Communications Security, Ericsson Research
Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
Tel: +46 8 585 317 07, GSM: +46 70 572 99 16, Fax: +46 8 404 70 20

This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you
in error, please notify the sender by replying to this transmission
and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to datacorruption,
interruption, unauthorized amendment, tampering and viruses, and
we only send and receive e-mails on the basis that we are not
liable for any such corruption, interception, amendment, tampering
or viruses or any consequences thereof.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 30 Jul 2008 11:18:00 -0400

Rolf Blom J <[email-masked]> writes:
>Thanks for all your comments. They really highlight the problems we have
>seen when we tried to design our solution for end-to-end security combined
>with hop-by-hop security in a store and forward application.
>
>We want to point out that the voice mail application is just one example
>application but we use it because it exhibits many of the problems
>encountered  including those that you have pointed ourt. Thus it is an
>excellent starting point for deriving requirements. If we can design a
>solution fulfilling those requirements we believe that all important store
>and forward applications would also be covered. In the next version of the
>draft we will expand on these other applications.
>
>We also want to make it clear that SRTP Store and Forward is intended for
>services where end-to-end security is the driving requirement. This means
>that users would be willing/have to abstain from services relying on the
>availability of plaintext, e.g for trancoding, speed-up, slow-down, etc.
>However, skipping in the media stream and other random seek functions
>would be possible with the proposed solution.

If you can't modify the timestamps and sequence numbers (and you can't if
you store-and-forward SRTP/SRTCP packets), skipping and seek are
problematic at best unless you also control the endpoint.  The only way I
see to do it is with a re-INVITE to effectively start a "new" stream
whenever you do any sort of "jump" in the stream.  Also, the re-INVITE
might not work if the endpoint responds with the same RTP port - it may
interpret the packets as out-of-order packets from the original INVITE
session.

That said, many RTP stacks (in order to deal with talking to other,
poorly-compliant clients) allow for resetting sequence and timestamp values
when the other side "jumps" (a rather arbitrary decision) - but a client
implementing strict security (or an SRTP library that's fairly strict about
replay attacks) might still refuse to do so.  Even if it does accept a
"jump", it may take a number of packets in a row before it does, and short
"jumps" would be assumed to be network issues.

>recorded encrypted media which would be used when retransmitting it.  We
>did not mention the need for the hint track as we wanted to focus on the
>pure security and SRTP issues.
>
>In the solution sketch the media payload is encrypted independently of the
>transport (RTP headers), and thus fulfills exactly the requirement stated
>by David Oran ("This makes any content privacy and integrity properties
>have to be independent of the transport privacy and integrity
>properties")  When protected media is forwarded with hop-by-hop protection
>a new and independent RTP/SRTP session will be initiated.

If the payload is encrypted separately from the headers in the initial
recording, this solves many of the above problems - but now the initial
connection (and the connection to the playback UA) are no longer SRTP (or
are SRTP, but containing an already-encrypted payload, thus
doubly-encrypting it, or by specifying a NULL encryption for the SRTP layer
- just authentication - to avoid double-encryption).

Note that these solutions all require endpoints that implement a new
set of RFCs/etc to support this, even to leave the message.