[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Posting in support for Protcol X, Y, or Z
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
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.
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
"R22: A solution SHOULD support media recording."
Does draft-wing-sipping-srtp-key-00.txt meet that requirement, from your