Re: Security for RTP connections - some thoughts

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

Werner Dittmann <Werner.Dittmann@xxxxxxxxxxx> wrote:
> While following most of the discussions about RTP, SRTP, key negotiations etc
> I wrote down my thoughts about some of the proposals discussed. It's not yet
> a finished document - just a set of thoughts, ideas, and experiences
> I made during other security implementations (WSS4J and alike).
> 
> Please have a look at the following page and look at the PDF file
> at that page.
> 
> http://www.fsfe.org/en/fellows/wernerdittmann

Hi Werner,

I just finished reading this document. Unfortunately, it seems
to me to embody some fairly serious misconceptions about TLS/DTLS
and DTLS-SRTP. In particular.

END-TO-END SECURITY
You claim that TLS/DTLS doesn't provide end-to-end security.
As I read your paper, you're making two arguments here.

1. It lives in the stack below the application layer protocol
   and therefore the application layer protocol has limited
   visibility into what's going on.
2. It can be terminated at a gateway as is commonly done with
   SSL/TLS accelerators.

With regard to the first point, it's true that TLS/DTLS lives below the
application layer protocol, but that does not preclude having end-to-end
security. It's conventional in Web browsers and servers to link the TLS
stack directly into the application and make calls directly to the TLS
stack. In this case, the application has more or less complete
visibility into what's going on in terms of security. As a practical
matter, nearly all protocol stacks isolate the security into some
library, so, for instance, if you're doing S/MIME (which I think pretty
much everyone would agree is e2e) the actual crypto is done in some
linked-in library. Indeed, this is how SRTP is conventionally done,
using libsrtp. TLS isn't really any different on this score.

The second point is true, but irrelevant. As a practical matter, all
protocols, even e2e ones, can be terminated at some gateway and passed
in cleartext to the final client *provided the endpoint cooperates*. To
take the example of S/MIME again, a common way to implement S/MIME is to
have encrypting gateways on the mail server to minimize client-side
impact. The key point here is that the endpoint has to cooperate. In the
S/MIME case, as with TLS accelerators, the endpoint which has outsourced
its processing knows that it has done so. Similarly, in both cases if
the endpoint *wants* to have a secure channel all the way through to the
other end (or at least to some proxy on the other end), it can do so as
well, and can have assurance that that's what happened.

As a thought experiment, consider a secure RTP-enabled phone which
also happens to be cordless. The base station does the SRTP and
then sends the data over the wireless channel to the handset.
Now, this channel may be encrypted (though it's probably not)
but it's almost certainly not SRTP. By the definition you're
suggesting this isn't end-to-end, but it should be clear that
no protocol can guarantee this property. (Modulo DRM-style
trusted hardware).


DEPENDENCE ON PKI
You claim that TLS/DTLS/DTLS-SRTP has a dependence on PKI. This is
fundamentally incorrect. It's useful here to read the introduction
to the most recent version of draft-fischl-sipping-media-dtls-02

   The media is transported over a mutually authenticated DTLS session
   where both sides have certificates.  The certificate fingerprints are
   sent in SDP over SIP as part of the offer/answer exchange.  The SIP
   Identity mechanism [I-D.ietf-sip-identity] is used to provide
   integrity for the fingerprints.  It is very important to note that
   certificates are being used purely as a carrier for the public keys
   of the peers.  This is required because DTLS does not have a mode for
   carrying bare keys, but it is purely an issue of formatting.  The
   certificates can be self-signed and completely self-generated.  All
   major TLS stacks have the capability to generate such certificates on
   demand.  However, third party certificates MAY also be used for extra
   security.

In other words, there's no dependence on PKI.

With regard to the comments you made about self-signed certificate life
cycle, most of those issues are irrelevant here because the certificates
are being used as key carriers, not in and of themselves. In particular,
this can all be hidden in the software internals and I would expect it
to be so. The one exception is when they are being used to provide an
identity continuity mechanism and you have to deal with compromise
of the information used to provide identity continuity. However, this
is an issue with *any* cryptographic continuity of identity system,
not just DTLS-SRTP.


Oh, one more note:
As Dan Wing indicated, DTLS-SRTP does support PFS cipher suites.

-Ekr