Subject: Re: [AVT] Media over DTLS

From: David McGrew <[email-masked]>
Date: Fri, 10 Mar 2006 08:16:42 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Mar 2006 12:03:53 -0500

A comment below on the NAT traversal pieces here.

>     the DTLS handshake is outside of the NAT or firewall, then

Thats true, but this is why we have ICE. The problem is not specific to 
DTLS; generally speaking, for RTP or any type of end-to-end 
communications, NAT will generally require the participant behind the 
NAT to initiate a request outwards towards its correspondent.  Its made 
more complicated by the fact that either the offerer or answerer or both 
could be behind such a NAT.

ICE solves this problem by providing each agent with the IP address of 
the other, so that each reaches out to the other with a STUN 
connectivity check. This will create the necessary NAT permissions to 
let subsequent communications occur.

As such, I believe that if you used ICE with DTLS, you would use ICE 
first to get the permissions in place, and then once the connectivity 
checks succeed, then run DTLS to secure the media stream. In this way, 
DTLS would "see" a clear IP channel and not need to worry about which 
end initiates or which end is behind NAT. It would just work.

Its also important to point out that NAT traversal really REQUIRES the 
offerer to receive the SDP answer, in order to learn the IP addresses 
and ports to which permissions need to be opened in the NAT. Thus, all 
of this discussion about completing various rounds of negotiation prior 
to receipt of the answer by the offerer are moot with NAT traversal; it 
is necessary. I'll note furthermore that this is not a consequence of 
the specifics of ICE; it is an unavoidable consequence of two things: 
(1) the separation of the media and the signaling on different ports, 
(2) the nature of NATs, requiring permissions to be installed before 
relaying packets from an outside entity. Any NAT traversal solution 
fitting within these constraints will have the same requirement, 
including SBCs.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Mar 2006 08:30:48 -0800

David,

Thanks for your comments and sorry about the slow response. As
with everybody, I'm totally swamped the week before IETF.

Some responses below.

> have been proposed.  See for example draft-mcgrew-srtp-ekt-00.txt

Right. So, what I was trying to get at here was the distinction
between what's actually done, which, as you say, is inadequate,
and what people have proposed to fix those inadequacies. There
have certainly been a number of examples of the latter, but my
impression was that none of them had yet achieved consensus.

> consider DTLS in "SRTP Compatibility Mode" the equivalent of a new

No, I don't. In particular because most of the transformations are
done without access to the keying material, most of the security
arguments about DTLS still obtain. The only transformations that are
cryptographic are CTR mode and partial encryption.  CTR mode is just a
new cipher suite and we have quite a lot of experience with designing
those, and of course, we can rip off design elements for CTR mode from
IPsec and SRTP. Re Partial encryption, TLS already has MAC coverage
for more of the packet than it encrypts, so we're basically extending
that. Given that TLS also has a NULL cipher, no, I don't think this
makes it a new protocol. Note also that we're not really having to
change the key management part of TLS (which is most of it) at all.

>      while RTP over DTLS only addresses point to point scenarios.

Well, it's important to distinguish between key management and
data transport here. Basically, RTP over DTLS addresses point
to point scenarios because that's what TLS/DTLS addresses
and it's the kind of key management we really know how to do.
In principle, yes, SRTP could be used for multi-unicast and
multicast scenarios, but the key management requirements
are so different that it seems to me that the primary barrier
here is the presence of a suitable key management protocol,
rather than of a data encryption format that supports both
modes. 

>      authentication tags on other data within the same session

These points are absolutely correct. Fundamentally, RTP/DTLS is
a profile of a generic security protocol (DTLS) with some
optimizations for a specific application (RTP). As such, we
unfortunately give up some flexibility. The rationale behind
this approach is that that's a good tradeoff in order to get
DTLS's well understood and flexible key management. I'd be
interested in your opinion on what specific applications would
suffer because of the difference.

>      the DTLS handshake is outside of the NAT or firewall, then

This is a bit outside my area of expertise, but I think JDR addressed
this point the other day.

>      length established prior to the start of the session.

Yes, this is a good catch. As I mentioned in my response to Lakshminath,
I don't have a good sense of how serious this is operationally.  Do you
know of applications where this is important?  It's of course
straightforward to fix this by having an indicator in the DTLS record of
how much data was enciphered. The drawback, of course, is some packet
expansion but maybe that's a price worth paying.

>      DTLS packet.  Is this intentional?  If so, where is this

No, this is an error. Thanks for the catch.

>      being distinct from the initial bits of the RTP header.  Is this

It's desirable but not mandatory. 

>     and used elsewhere for use in the VoIP context.

You're right. My bad. I was trying to present an accurate picture
of the bandwidth situation, but I got a little excited trying
to make the smallest SRTP packet I could :)

>      extensions. 

They're not. I got a little carried away with trying to cover all
the different optimizations one should be able do :)

>      The number and complexity of these options show that

I don't really agree that it's misleading, but I definitely think
it would be good to lay out the arguments for why you should be
comfortable with these modes. This is getting long enough as it
is, so I'll do that in a future note.

>      that it is not.

Hmm... I don't see any likely problems. Can you explain what you're
concerned about?

>      One point that needs to be considered is that a

This is a fair point, but with an 80-bit MAC, I don't think the
reduction in security is likely to be that serious.

>      redundancy check on the decrypted material, and if so, what

This should absolutely say trial authentication. Loose speaking on
my part.

>      so, how?  Is it capable of working with FEC with either order

I'm not familiar enough with FEC to give you a definite answer.
Can you explain the problem you suspect?

>       introduce costly additional and superfluous public key

Well, it's probably a mistake to conflate SRTP and key management
here. DTLS is primarily aimed at fixing the difficulties people are
having with the existing key management schemes that are being
proposed for SRTP. So, it's tricky to compare DTLS with a hypothetical
alternative scheme that would have all the properties we want.

That said, certainly any public key mode is far slower than
SDESCRIPTIONS or MIKEY symmetric key mode since both involve no public
key operations at all. If you can use session resumption, then the
DTLS/RTP modes have fairly comparable performance to the MIKEY
equivalents.  If you can't use session resumption, then yes, DTLS is a
bit slower.  On the other hand, DTLS supports an RSA mode which doesn't
have the certificate discovery problem that MIKEY's RSA mode has, so
DTLS's RSA handshake requires fewer private key operations than MIKEY's
DH mode.

I don't really understand your objection about self-signed certs,
for several reasons:

1. You don't actually need to verify the certificate at all.
   It's only being used as a cert carrier. You just need to
   verify the digest. The TLS handshake itself provides POP
   for the private key.

2. RSA public key operations are far faster than RSA private
   key operations (typically 20x), so the bulk of the computational
   cost in a TLS handshake is the private key operations.

>      relative to RTP-over-DTLS?

This is a very interesting suggestion. My primary concern with a method
of this kind would be that there was tight enough integration between
the SRTP and the DTLS key management that we don't see synchronization
and state machine problems. But that's not to say at all that it couldn't
be made to work. I'll just need to think about it a bit more.

-Ekr