Re: [AVT] Media over DTLS

[David McGrew <[e-mail]>]

Eric,

I have a lot of comments and questions about your work, please see  
below.

> 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.

That's not really true. SDP security descriptions with SDP security  
preconditions solves these problems, but at the cost of an extra  
round trip in the signaling plane.  As it has become evident that the  
preconditions approach isn't desirable, and number of other methods  
have been proposed.  See for example draft-mcgrew-srtp-ekt-00.txt

> This set of
> drafts addresses these issues. Instead of inventing a new key
> negotiation protocol,

There's a lot of new text that you're referencing - wouldn't you  
consider DTLS in "SRTP Compatibility Mode" the equivalent of a new  
protocol?

> it uses DTLS for key establishment and algorithm
> negotiation while having the same on-the-wire packet format as SRTP.

But unfortunately the format compatibility doesn't give us any  
interoperability with SRTP; please see comment number 12 below.

>
> 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

I've itemized my points below for convenience in discussion.

Best regards,

David

--

1.  SRTP works in group scenarios (both multi-unicast and multicast),
     while RTP over DTLS only addresses point to point scenarios.

2.  RTP over DTLS does not provide all of the security policy options
     that SRTP allows.  For example, an SRTCP sender can selectively
     choose which SRTCP packets to encrypt, and SRTP can allow short
     authentication tags on conversational voice media, but long
     authentication tags on other data within the same session
     (e.g. DTMF digits).

3.  RTP-over-DTLS appears not to work with Symmetric RTP [6].  That
     RTP method is commonly used in order to allow RTP sessions to
     traverse NAT and firewall devices.  This facility relies on the
     fact that the media source behind the NAT sends data that triggers
     a NAT translation that allows inbound media.  If the initiator of
     the DTLS handshake is outside of the NAT or firewall, then
     RTP-over-DTLS will fail.

4.  The partial encryption extension [2] does not properly handle RTP
     header extensions.  That extension negotiates some number of
     initial bytes that will be unencrypted in each packet.  However,
     it is desirable to leave the RTP header extension unencrypted
     whenever it is present (not encrypting the header is the first
     goal named for "SRTP Compatibility Mode"), and this facility does
     not allow that.  It would require the RTP application to choose in
     advance to use or not use an RTP header extension with some fixed
     length established prior to the start of the session.

     A security protocol for RTP should not constrain which RTP
     applications can be supported, but items 1,2,3 and 4 put
     significant constraints on the applications.  SRTP is flexible
     enough to have been adopted for use with many diverse RTP
     applications, both inside and outside of the IETF; see
     http://srtp.sourceforge.net/spec.html#Uses for example.
     RTP-over-DTLS lacks the ability to work with many of these
     applications.

5.  In Appendix A.3 of [3].  An "SRTP MKI" field is included in the
     DTLS packet.  Is this intentional?  If so, where is this
     field defined?

6.  RTP over DTLS appears to rely on the DTLS "content type" field
     being distinct from the initial bits of the RTP header.  Is this
     right?

7.  The RTP over DTLS spec [3] says that "DTLS uses a 10 byte MAC and
     SRTP uses a 4 byte MAC".  This is misleading; a ten-byte MAC is
     defined in the SRTP standard, and is the default and recommended
     value for the protocol, though a four-byte MAC has been defined
     and used elsewhere for use in the VoIP context.

8.  The RTP over DTLS "SRTP Compatibility Mode" requires a large
     number of extensions to DTLS (which itself is a significant
     extension to TLS):

       The TLS partial encryption extension, with an InitialPlaintext
       value equal to the length of the RTP header [2],

       The DTLS implicit application data header [1],

       The TLS MAC truncation extension [4],

       The Counter Mode cipher [5]

     It is not clear whether or not the other extensions defined in [1]
     - sequence_number_length, no_version_field, no_length_field - are
     also required, or perhaps are implicitly required by the other
     extensions.  The number and complexity of these options show that
     the claim "because RTP/DTLS runs over DTLS, which is based on TLS,
     which has seen extensive security analysis, we can have fairly
     high confidence in the security of the system" (Section 7 of [3])
     is misleading.

9.  TLS does decryption before a MAC check.  When combined with
     partial decryption, this may be a potential security problem - at
     the very least, some analysis would need to be published showing
     that it is not.  One point that needs to be considered is that a
     receiver that performs multiple guesses, each followed by an
     authentication check, is weakening the authentication in doing so.
     In SRTP, we very consciously did not recommend this method.

     [1] now says that "The "implicit_header" extension introduces some
     ambiguity in record receipt processing.  This ambiguity can,
     however, be resolved by trial decryption."  Shouldn't this state
     that the message authentication check is used to resolve the
     ambiguity, rather than an encryption?  Or is there some
     redundancy check on the decrypted material, and if so, what
     is that check?

10. Does RTP/DTLS work with RTP Forward Error Correction [7], and if
     so, how?  Is it capable of working with FEC with either order
     of processing?

11.  The performance of RTP/DTLS will lag behind that of the SRTP
      alternatives.  It will require two TLS handshakes - one for RTP,
      and one for RTCP - and at least one full handshake's worth of
      certificate validation as well as a public key
      encryption/decryption or a public key exchange.  Another
      performance demerit is the fact that, because decryption precedes
      an authentication check, trial decryption must be done in
      RTP-over-DTLS, unlike SRTP.  Also, self-signed certificates
      introduce costly additional and superfluous public key
      operations.

12. The "SRTP Compatibility Mode" of [3] is not really compatible with
     SRTP - it does not interoperate with SRTP in any way.  Wouldn't it
     be preferable if it was compatible in an interoperable way?

     The advantage of RTP-over-DTLS is that it re-uses the TLS
     handshake, thus providing a built-in key management method.  The
     way to achieve this advantage while retaining SRTP's advantages is
     to define a way to use that handshake to provide keying material
     to a media-protection method that is actually compatible with
     SRTP.  This way, the advantages of the DTLS handshake could be
     used in scenarios in which it is useful, while other keying
     methods could be used in other scenarios, with only a single
     implementation of a media-security layer.  This interface
     is already defined for SRTP in Section 8.2. of RFC 3711.

     This SRTP-interoperable method is better suited to constrained
     environments where SRTP is much easier to support because of its
     smaller code size.  It also would enable significant code re-use,
     especially for all of the devices that already implement SRTP.

     There are many ways that a DTLS handshake could be used
     to establish SRTP keys.  One simple method that is obviously
     secure is to pass SRTP keying material over a DTLS connection
     that has been established for that purpose.  The following
     text expresses the SRTP key management interface in terms
     of the TLS presentation layer:
     enum { null_cipher, aes_128_icm, aes_128_f8 } srtp_cipher_type;

     enum { null_auth, hmac_sha1_80 } srtp_auth_type;

     enum { aes_cm } srtp_kdf_type;

     struct {
       uint32           ssrc;
       srtp_cipher_type cipher_type;
       srtp_auth_type   auth_type;
       srtp_kdf_type    kdf_type;
       uint8            cipher_key_size;
       uint8            auth_key_size;
       uint8            cipher_salt_size;
       opaque           cipher_key[32];
       opaque           cipher_salt[32];
       opaque           auth_key[32];
     } srtp_parameters;


     What disadvantage would an SRTP-interoperable method have
     relative to RTP-over-DTLS?


References


    [1] Modadugu, N. and E. Rescorla, "Extensions for DTLS in Low
        Bandwidth Environments", draft-modadugu-dtls-short-00 (work in
        progress), October 2005.

    [2] Rescorla, E., "TLS Partial Encryption Mode",
        draft-rescorla-tls-partial-00 (work in progress), January 2006.

    [3] Tschofenig, H., Rescorla, E., "Real-Time Transport Protocol
        (RTP) over Datagram Transport Layer Security (DTLS)", February
        25, 2006

    [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
        Wright, T., Transport Layer Security (TLS) Extensions, RFC
        2246.

    [5] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites
        for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in
        progress), October 2005.

    [6] Wing, D., Common Local Transmit and Receive Ports (Symmetric
        RTP) draft-wing-behave-symmetric-rtprtcp-01

    [7] J. Rosenberg, H. Schulzrinne, An RTP Payload Format for Generic
        Forward Error Correction, RFC 2733.


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt