Re: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01

I agree.  Since the (only) major advantage of SDES is its widespread deployment,
it makes little sense to introduce patches that are unlikely to be widely implemented,
particularly when they introduce other security problems.   

> From: ekr@rtfm.com
> Date: Mon, 17 Sep 2012 09:29:33 -0700
> To: mmusic@ietf.org
> Subject: [MMUSIC] Comments on draft-zhou-mmusic-sdes-keymod-01
> 
> This document describes an extension to SDES to address the fact that
> in the case of retargeting/forking multiple targets get to see the
> SDES key which the offerer will use for sending data. The proposal
> here is to add an extension which can be sent by the answerer to
> modify the key provided by the offerer.
> 
> 
> This whole line of development doesn't seem like a very good idea.
> During the RTPSEC work, we considered this problem and a bunch of
> related problems with SDES (e.g., early media) and concluded that a
> media-plane key establishment protocol was the right approach to
> addressing this problem, among others.  I don't see a lot of point in
> doing piecemeal patches to SDES in an attempt to band-aid it's
> fundamental problems.
> 
> 
> This particular design seems particularly problematic in that
> it allows an on-path proxy to force the offerer into using a
> specific key. The general pattern would look like this:
> 
> Alice                    Proxy                    Bob
> 
> OFFER with K1 + keymod --->
>                             OFFER w/ K2 ------------>
>                             <----------------- ANSWER
> <- ANSWER with Keymod for K2
> 
> 
> With conventional SDES, the proxy gets to see the SDES key but
> not to modify it. Obviously, he can change the key in flight,
> but the sender will still use the old key. This design would
> further weaken even the limited set of protections provided
> by SDES.
> 
> 
> -Ekr
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic