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

[Eric Rescorla <[e-mail]>]

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