[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Security for RTP connections - some thoughts
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.
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.
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
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
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
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.