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

On Jun 13, 2013, at 5:59 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 06/13/2013 01:07 PM, Tim Panton wrote:
>> I fear it just _looks_like_ the primary interop issue.
>> 
>> As I recall when we last , the main reason that SDES is required is to facilitate sane multiuser conference video switching without
>> the hub box having to decrypt-encrypt every channel. (I vaguely remember Hadriel had a centerbox with flames coming out of it in his diagram in Paris)

It was my presentation at IETF83 in Paris.

>> Unfortunately the plan-a-plan-b-no-plan discussion shows that usecase isn't gonna work trivially even if we do have SDES.
>> 
>> The other reason I can see is that there is an additional round-trip in the call setup, which does add some delay.
>> 
>> I'm not convinced by the 'interop with older devices' argument. Anything that has been upgraded to deal with ICE and the fattened SDP can also have DTLS added at the same time. Anything that isn't upgraded isn't going to work anyway.
>> Based on my experience adding DTLS isn't a huge amount of work. ICE and SDP changes were much more time consuming.
> 
> 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.

Right -- EKT is what makes the flames go away.  Slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf shows the flames, and the flames go away when we add EKT on slide 33.

> 
> If the WebRTC world does not support EKT, then decrypt/encrypt will work in all cases.
> 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.
> 
> 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".
> 
> Agree with Tim about the relative difficulty of adding the needed features.

-d

> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb