Gutmann Soundwave Therapy

[Eric Rescorla]

At Sun, 03 Feb 2008 12:51:25 +1000,
James A. Donald wrote:
> 
>      --
> Ivan Krstic' wrote:
>  > The wider point of Peter's writeup -- and of the
>  > therapy -- is that developers working on security
>  > tools should _know_ they're working in a notoriously,
>  > infamously hard field where the odds are
>  > _overwhelmingly_ against them if they choose to
>  > engineer new solutions.
> 
> That point is of course true.  But the developers wanted
> to transport IP and UDP.  Peter should have known that
> SSL is incapable of transporting IP and UDP, because it
> will introduce large, unpredictable, and variable
> delays.
> 
> If, for example, VOIP goes over SSL, the speakers would
> become entirely unintelligible.

For those who haven't already made up their minds, the situation with
VoIP and TCP (SSL doesn't really change the situation) is actually a
bit more complicated than this.

1. VoIP over TCP
If you have a reasonably fast loss-free channel (this isn't that
uncommon) then it doesn't actually make an enormous amount of
difference whether you're running TCP or UDP, especially if you're
running a high-bandwidth codec like G.711. It helps to turn off the
Nagle algorithm, of course, since it reduces the amount of buffering
in the sending TCP stack.

That said, any significant amount of packet loss does tend to create
some pretty significant artifacts, since you need to stall the
receiving TCP while you wait for the retransmit.  So, as a practical
matter nearly all interactive VoIP systems use UDP and some kind of
packet loss concealment (interpolation, etc.).

That's not to say that SSL/TLS is totally innocent here. The designers
of SSL/TLS *could* have chosen to design a protocol which would work
over datagram transport as well as stream transport, but they didn't.
DTLS (RFC 4347) is such a protocol. That said, if you compare DTLS to
TLS, there is a small amount of additional complexity in DTLS, so it's
arguable that it was a good design choice to go for the sweet spot of
stream transport, since that's what SSL was really intended for.


2. VoIP over DTLS
As Perry indicated in another message, you can certainly run VoIP
over DTLS, which removes the buffering and retransmit issues 
James is alluding to. Similarly, you could run VoIP over IPsec
(AH/ESP). However, for performance reasons, this is not the favored
approach inside IETF.

The relevant issue here is packet size. Say you're running a 
low bandwidth codec like G.729 at 8 kbps. If you're operating at
the commonly used 50 pps, then each packet is 160 bits == 20 bytes.
The total overhead of the IP, UDP, and RTP headers is 40 bytes,
so you're sending 60 byte packets. 

- If you use DTLS with AES in CBC mode, you have the 4 byte DTLS
  header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC
  mode), plus 2 bytes of padding to bring you up to the AES block
  boundary: DTLS adds 32 bytes of overhead, increasing packet
  size by over 50%. The IPsec situation is similar.

- If you use CTR mode and use the RTP header to form the initial
  CTR state, you can remove all the overhead but the MAC itself,
  reducing the overhead down to 10 bytes with only 17% packet
  expansion (this is how SRTP works)

Note that some (but not all) of the gain from SRTP can be obtained
by swapping CTR for CBC. But you're still getting an advantage
from being willing to overload the RTP header and that's harder
to optimize out (though Nagendra Modadugu and I spent some time
thinking about this).

I don't propose to get into an extended debate about whether it is
better to use SRTP or to use generic DTLS. That debate has already
happened in IETF and SRTP is what the VoIP vendors are doing. However,
the good news here is that you can use DTLS to key SRTP
(draft-ietf-avt-dtls-srtp), so there's no need to invent a new
key management scheme.

-Ekr















---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com