Re: [AVT] Media over DTLS

[Lakshminath Dondeti <ldondeti at qualcomm.com>]

Eric,

After reviewing some of these drafts, I find them to be somewhat 
scant on details and it is hard for an independent observer to reach 
the same conclusions you have.  My observations are as follows (and I 
will provide detailed reviews of as many of these drafts as I 
can).  I do appreciate your expertise in the SEC area and in TLS/DTLS 
specifically, so please feel free to point out where I may have misunderstood.

First, as Mark points out, there has been a bundle of work trying to 
solve the early media and forking issues.

Second, it is not clear how DTLS or DTLS-SHORT addresses those 
issues.  Could you please elaborate?  (I have read the motivation 
section of sipping-media-dtls, but that's not convincing).

Next, you note that you are reusing DTLS, yet I find DTLS-SHORT to be 
a quite complex variation of DTLS, and I for one would like to see a 
security analysis of all the extensions and modifications to DTLS 
before we conclude that DTLS-SHORT is equivalent to DTLS.  It may be 
clear to the authors, but it is not clear from the text in the I-Ds.

DTLS or DTLS-SHORT do not have the same on-the-wire packet format as 
SRTP, unless you make liberal assumptions about optional fields.

SRTP also has certain capabilities that DTLS does not have.  Of 
course, as with DTLS-SHORT, you can continue to tweak DTLS to look 
and behave like SRTP.  But, it is not clear what DTLS offers that 
MIKEY+SRTP for instance don't, and why we need this elaborate 
exercise of tweaking DTLS to behave like SRTP, instead of just using 
the latter (it has been around for a long while now and a lot of 
other SDOs use it quite satisfactorily).  Please elaborate!

Regarding things SRTP does and DTLS does not support at the moment, 
SRTP allows reuse of master key for multiple senders, supports 
conferencing and broadcast distribution very well.  SRTP's ROC 
maintenance is much more clear and seems easier to process than the 
epoch+sequence number elimination between DTLS and DTLS-short 
protocols.  In SRTP, integrity verification comes before decryption 
and provisional processing of packets as in DTLS-SHORT or in SRTP (in 
case of ROC synchronization issues).  If checksum verification fails, 
there is no need to decrypt also during the trial-and-error process 
to guess the ROC (with the usual caveats of course).

thanks and regards,
Lakshminath

At 03:59 PM 3/2/2006, Eric Rescorla wrote:
> Hi,
>
> AVT working group members may be interested in the following suite
> of drafts, which define a method for securing multimedia (especially)
> RTP traffic using DTLS:
>
> http://www.ietf.org/internet-drafts/draft-fischl-sipping-media-dtls-00.txt
> http://www.ietf.org/internet-drafts/draft-tschofenig-avt-rtp-dtls-00.txt
> http://www.ietf.org/internet-drafts/draft-fischl-mmusic-sdp-dtls-00.txt
> http://www.ietf.org/internet-drafts/draft-modadugu-dtls-short-00.txt
> http://www.ietf.org/internet-drafts/draft-rescorla-tls-partial-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt
>
> Why is this interesting? SIP does not have a scheme for key negotiation
> of media encryption that works with early media and forking. This set of
> drafts addresses these issues. Instead of inventing a new key
> negotiation protocol, it uses DTLS for key establishment and algorithm
> negotiation while having the same on-the-wire packet format as SRTP.
>
> HTML versions can be found at:
>
> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/{draft}.html
>
> The draft of most interest to this WG is probably
> draft-tschofenig-avt-rtp-dtls-00 but you may find it helpful to read
> draft-fischl-sipping-media-dtls-00 first for background.
>
> -Ekr
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt