[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Dave,

On Jul 29, 2008, at 5:26 AM, David R Oran wrote:



On Jul 29, 2008, at 8:13 AM, Dan Wing wrote:





-----Original Message-----
From: Rolf Blom J [mailto:rolf.j.blom at ericsson.com]
Sent: Tuesday, July 29, 2008 11:09 AM
To: Dan Wing; David McGrew
Cc: AVT
Subject: RE: [AVT] question on
draft-mattsson-srtp-store-and-forward-00.txt

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


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


-d



/Rolf and John



-----Original Message-----
From: Dan Wing [mailto:dwing at cisco.com]
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




-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On

Behalf Of

David McGrew
Sent: Monday, July 28, 2008 8:21 PM
To: john.mattsson at ericsson.com;
fredrik.lindholm at ericsson.com; yi.cheng at ericsson.com; 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,

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.


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-trans
port-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







_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt