Re: [MMUSIC] Feedback requested on requirements - DES F13

[[e-mail] (Dale R. Worley)]

Answering messages from Magnus and Christer regarding DES F13:

> From: Magnus Westerlund <[e-mail]>

> >    DES F13  It is desirable for RTP media to appear on the wire as
> >       (encrypted) SRTP packets and for RTCP reports to appear on the
> >       wire as (authenticated but not encrypted) SRTCP packets.  Thus,
> >       encryption of RTP/RTCP via DTLS and encapsulation of multiplexed
> >       packets is not desirable.
> 
> I am not certain I understand the motivations for this requirement. Is
> the need to having unencrypted RTCP for third party monitors? From a
> security point of view I see issues with such blanket statements. There
> can be information in the RTCP that is sensitive for privacy reasons.

I omitted the discussion of this desideratum:

   This desideratum was suggested by Martin Thompson (http://
   www.ietf.org/mail-archive/web/mmusic/current/msg10400.html) and Dan
   Wing (http://www.ietf.org/mail-archive/web/mmusic/current/
   msg10408.html).

The two referenced messages are:

    From: Martin Thomson <martin.thomson at gmail.com>
    Date: Wed, 27 Feb 2013 14:11:21 -0800
    Cc: "mmusic at ietf.org" <mmusic at ietf.org>

    There are no security reasons why this wouldn't work.  Some
    applications already do this.

    The actual problems are manifold:

     - SRTP was designed to have a low per-packet overhead.  The DTLS
    record layer has a larger per-packet overhead.
     - SRTP exposes certain attributes in clear text for intermediaries to
    use.  Intentionally.  Using DTLS would lose this.
     - SRTP enjoys wide support.  This would harm interoperability with
    existing communication devices, forcing the use of more complex
    gateways.

    From: "Dan Wing" <dwing at cisco.com>
    Date: Thu, 28 Feb 2013 14:51:52 -0800
    Delivered-to: mmusic at ietfa.amsl.com

    SRTP (RFC3711) was carefully and purposefully designed so the RTP header 
    remains in the clear, and DTLS-SRTP was also purposefully designed so
    after the DTLS-SRTP handshake establishes the SRTP keys, the SRTP packets
    flow over the wire exactly like they would for any other keying 
    mechanism (ZRTP, MIKEY-*, Security Descriptions).

    By sending SRTP packets with their RTP header in the clear, it allows:
      * the RTP header to be compressed (cRTP [RFC2508], ECRTP [RFC3545])
      * analysis devices to see where, on a network path, SRTP packets 
	are lost, delayed, or get mis-ordered.
      * analysis devices to see SRTCP receiver reports and sender reports,
	which are typically authenticated but in the clear.

The reason I document this as a requirement for bundling is that it
excludes certain uses of cryptography and more importantly, it
excludes encapsulation techniques.

> For the last sentence are you really meaning DTLS or DTLS-SRTP. There is
> a big difference here.

I may be misusing the terminology, but I believe that "DTLS-SRTP" is
"providing keying for SRTP using DTLS", whereas the phrase I used is
"encryption of RTP/RTCP via DTLS", which is what I intended.

> From: Christer Holmberg <[e-mail]>

> I am not sure I understand why this is bundle specific.

This requirement excludes techniques that use encapsulation, so it is
a significant constraint on acceptable bundling techniques.

Dale