[AVT] Review of store and forward drafts

[Eric Rescorla <ekr at networkresonance.com>]

$Id: draft-mattson-srtp-store-and-forward-02-rev.txt,v 1.1 2009/04/06 22:43:10 ekr Exp $

Also draft-naslund-srtp-saf-00.txt

These documents describe a set of use cases and a protocol for a
modification to SRTP to do "store and forward". I have several
concerns:

- Are these use cases actually compelling?
- Do these use cases all need the same set of mechanisms?
- How is key management really going to be done for these.
- How realistic is the threat model?

The use cases here fall into two major categories:

- media distribution
- recording media on answering machines/voicemail servers
- untrusted conference bridges

It's not clear to me that these are really that similar problems.  In
particular, the media distribution cases mostly seem to me to be cases
in which what's needed is to temporally decouple message integrity
from confidentiality so that you can avoid storing bogus data which is
only determined to be bogus when you go to replay it. This is
particularly noticeable in the "Recording Encrypted Media at Home"
example (S 4.2.4) where there's no real need to treat the DVR as
untrusted--you just want to be sure that the media is correct at the
time you record it even though you don't have a license for the media
yet.

I agree that the voice mail case requires something more substantial,
however it's also much less compelling. First, it's not clear to me
that people really don't trust their voice mail servers. Second, voice
mail servers do a fair amount of mixing (for instance, prompts) with
the media. As I said on the call, I'm skeptical that existing phones
will handle this well. Third, it requires a key management scheme
we don't have: in order for this use case to work, you need a way
for the sender of the voice mail to do offline key exchange with
the ultimate receiver. If this worked well, we wouldn't have had 
any need for RTPSEC to solve the special case of online key exchange!

The untrusted conference bridge case seems even less compelling, 
because real bridges do a lot of fancy audio stuff.

Another concern I have is that the threat model seems fairly
unrealistic. Why is it safe to assume that the middlebox which
is not allowed to see the media is nevertheless allowed to retime
it and mount generic cut-and-paste attacks? I appreciate you
have a countermeasure for that, but that countermeasure relies
on a separate integrity check and basically precludes much of
the point of this work, it seems to me.

At the end of the day, I wonder whether there is a simpler scheme in
which we simply partition the authentication and encryption
transforms so that disconnected keys can be used for each. ISTM
that this would allow the most interesting set of use cases
(those concerned with media distribution) with significantly
less effort. Yes, I realize that it wouldn't provide quite
the same level of integrity protection, but it's not clear
that that's really necessary. To the extent to which you *do*
want to double-wrap the data, it's not clear to me that doing
it again in SRTP is really that useful: a lot of the point of
SRTP is that it leverages existing headers for maximum data
compactness. Once you're doublewrapping and adding new headers
like e2e PUV, maybe you could just get away with an outer
DTLS wrapper without any SRTP extensions