Re: [rtcweb] No Interim on SDES at this juncture

[Bernard Aboba <[e-mail]>]

Harald said: 

> The architectural/non-cost argument I see against decrypt/encrypt is 
> "the gateway wants to be able to disclaim the ability to look at the bits".

[BA] There are only a limited number of situations where it is possible to "disclaim the ability to look at the bits".  For example, a PSTN gateway, PBX connecting to a SIP trunk, a video compositor or an audio mixer need to access decrypted RTP packets in order to do their job.  What non-P2P scenarios are you imagining where that would be possible? 
 
> My impression from the performance numbers people have quoted is that 
> the CPU cost of decrypt/encrypt doesn't cost enough to be the 
> deal-breaker between "viable solution" and "not viable solution"; other 
> things weigh far more on capex/opex.
 
[BA] I believe it is correct to say that the CPU cost of SRTP encrypt/decrypt  is not the bottleneck in large membership conferences (a good MCU implementation running on a high-end multicore server is likely to saturate a 1 Gbps NIC before CPU utilization becomes a factor).  Given that, I don't see that EKT will actually have that much impact, compared with other decisions about the key exchange -  whether PFS is required, key establishment algorithms and key sizes, etc.  For example, see: 
http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html