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

[[e-mail]]

Hi, Eric and Bernard,
 
 Sorry for the late reply, I somehow missed a lot of emails from the list.

 Concerning your commonts, I have the following responses:

 1. I agree SDES is not a secure solution in all kinds of key 
agreements/transportation protocols.
 2. The extension I proposed in the draft brings no more problem to the 
original SDES, the problem you
described is misleading. 
   Firstly, the key transportation in SDES is protected by other 
protocols, such as TLS, that is the important assumption.
         without the assumption, it is useless to discuss the security of 
SDES, how can you expect a protocol sending key in plaintext to be called 
secure?
         Under this assumption, the Proxy trying to modify the key does 
not exist, intermediate servers in the path are assumed trusted, the only 
possible Proxy attacker is 
         one of the forking terminals, if such a terminal triggers Alice 
into using an arbitrary key,  the key will be used between Alice and the 
attacker terminal.
 Secondly, the aim of SDES is to protect transported information in 
confidentialty and integrity, 
         in the original SDES, if no additional protection is to be 
applied to SDES, any one on path can see the key, and can obtain the 
plaintext, modify it.
         in the extensioned SDES, the attacker can modify the key of the 
sender, then what else he can obtain besides plaintext and modifying it? 
         Consider if one solution is more secure than another, I think the 
evaluation must be done according to the same goal. 
         An example: 
            the first case. a thief can get any key to  the door lock 
somehow, so the thief can get into the house any time;
            the second case. the thief is the door lock provider, and he 
obviously keeps a copy of any key he sells out. 
            Which one do you think is more weaker or more secure?
 
 

"
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 at rtfm.com
> Date: Mon, 17 Sep 2012 09:29:33 -0700
> To: mmusic at 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
"