Re: [secdir] [Sipping] draft-wing-sipping-srtp-key-04 (was no subject)

[Hadriel Kaplan <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Eric Rescorla
> Sent: Sunday, February 15, 2009 11:59 AM
>
> This document describes two major use cases for this type of
> technology:
> - Monitoring (call recording)
> - Transcoding
> I don't think it's particularly useful to conflate these cases, which
> are really quite different.

I agree - it's really, really weird to think of transcoding cases doing things this draft's way. (in fact it's hard to believe call recording apps should work this way either, but I know they want to)


> Similarly, this document fails to distinguish adequately between
> real-time and non-real-time use cases. Many monitoring/call recording
> applications are inherently non-real-time: you record the call
> and some time in the future, the call may or may not be replayed.

I used to think that too, but I've come to find out that some call monitoring apps really do need real-time play-back; because it's not "play-back", it's like a 3-party conference with a silent listener.  For example some support call centers have managers who listen in on active calls randomly, or listen in to newly-hired staff for the first day or so.
Also, some vertical markets must successfully record all calls, for legal reasons, and even the chance of the keys getting lost due to phone reboots or whatever is not acceptable to them.  So I think getting the keys at the beginning of the call is a requirement.


> Finally, the elephant under the covers here is lawful intercept.
> the authors specifically disclaim it, but it's quite clear that
> this is usable as an LI system. Indeed, many such systems
> (e.g., FORTEZZA) involve cooperation from the endpoint being
> monitored.

I actually believe them that it's not applicable.  Most LI systems cannot work like FORTEZZA, specifically because they cannot let the user know he/she is being tapped and cannot rely on cooperation.  I don't think any self-respecting LI system would rely on the endpoints to give it keys. :)

Besides, pretty much any Call Monitoring application has unavoidable similarities with Lawful Interception.  The same could be argued for Troubleshooting mechanisms too.  So what/who cares?  We cannot and should not define a mechanism for LI in the IETF; but that doesn't mean we can't define mechanisms for other purposes, which may also happen to be usable as LI mechanisms.


> DETAILED COMMENTS
> 4.3.
> If the requirement for recording is this strong, wouldn't it
> be better not to rely on the UA doing the right thing? Rather
> enforce it in a firewall or IDS.

Yeah, this is whacked.  The whole mechanism is odd, imho.  If you need to record calls in a call center, use keys in signaling the B2BUA can see, or terminate the SRTP at the B2BUA.  It's not as secure as DTLS-SRTP end-to-end, obviously, but it's not as secure as that anyway in this draft's mechanism.  You're already trusting middleboxes with the keys in this draft's mechanism, so trust them with the keys a priori.

Also, as an aside - using SIP to-from the recording server makes no sense.  You can pretend it's a 3-party conference call, but it's not true.  It will really get confusing when calls get REFER transferred, for example.  I know some vendors want to do this, but it's a really bad idea.  They're gonna be in a world of hurt spending all their time troubleshooting and enhancing their SIP stacks to handle this odd model for every corner case, instead of spending it on their business-specific application logic.  Just because SIP is a hammer doesn't mean this application is a nail.

-hadriel