Re: [AVT] Media over DTLS

[Eric Rescorla <ekr at networkresonance.com>]

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.

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

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.


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

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.


> 1.  SRTP works in group scenarios (both multi-unicast and multicast),
>      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. 


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

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.


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

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


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

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.


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

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


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

It's desirable but not mandatory. 


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

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



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

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

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.


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

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

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.




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

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


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

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



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


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.



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

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



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