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

[Hadriel Kaplan <[e-mail]>]

On Jun 13, 2013, at 8:59 AM, Harald Alvestrand <[e-mail]> wrote:

> My impression from Paris was that if the WebRTC world supports EKT, then gatewaying into an SDES realm requires some fancy key-shuffling, nothing more.

My impression from the discussion there was: "we have this new shiny toy no one's ever deployed so why don't we use you as the guinea pig".  In fact if I recall correctly it was you who said something along those lines in Paris. :)


> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.

Yup.


> 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.

Yes, I also think that's true, that the cost/complexity overhead of decrypt/encrypt wouldn't break the viability.  It does cost more to do it, though, so if we can get away without having to do it (without truly sacrificing security) then it would be a good thing.  Things add up after all, both in processing cost and time.

But yes clearly it isn't as big a deal as having to transcode video, for example, which would not be viable.


> 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".

I hadn't heard that one.  I'm not really sure how one could prove that anyway though, since SDES would certainly give the gateway the *ability* to look at the bits.  You would have to either check the code or believe the logs, and if you're willing to believe them then you might as well believe the code/logs that the gateway isn't storing/sampling the bits when it decrypts/encrypts.


> Agree with Tim about the relative difficulty of adding the needed features.

Afaict, adding SDES is trivial if you went to the trouble of doing DTLS-SRTP already.  The converse isn't true.

-hadriel