Decrypting middleboxes make me really uncomfortable from a security point of view. If your protocol accommodates middleboxes, how does it distinguish between authorized and unauthorized middleboxes? It would be best to keep this consideration out of the key management / negotiation protocol, and address it instead through out-of-band key transport (e.g., draft-wing-sipping-srtp-key). This would allow specific middleboxes (e.g., those authorized to subscribe to key notifications) to get keys quickly, without the key exchange protocol having to support men in the middle. (I guess I'm advocating for a solution that supports ONLY end-to-end, with a side-band for giving out keys.)
On the other hand, I do think it's reasonable to expect that there will be boxes in the media path that will be doing other things to packets (besides decrypting), like the firewalling and QoS. These things I think certainly should be accommodated.
Cheers, --Richard Dan Wing wrote:
...I also strongly think that we need to support middleboxes in the network, which may need to decrypt the media. The usage of a solution which supports ONLY end-to-end is going to be very limited.We have that captured in requirement R22 of draft-wing-media-security-requirements-01.txt: "R22: A solution SHOULD support media recording." Does draft-wing-sipping-srtp-key-00.txt meet that requirement, from your perspective? -d