Gutmann Soundwave Therapy

[Eric Rescorla]

At Mon, 4 Feb 2008 09:33:37 -0500 (EST),
Leichter, Jerry wrote:
> 
> Commenting on just one portion:
> | 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)
> If efficiency is your goal - and realistically it has to be *a* goal -
> then you need to think about the semantics of what you're securing.  By
> the nature of VOIP, there's very little semantic content in any given
> packet, and because VOIP by its nature is a real-time protocol, that
> semantic content loses all value in a very short time.  Is it really
> worth 17% overhead to provide this level of authentication for data that
> isn't, in and of itself, so significant?  At least two alternative
> approach suggest themselves:
>
> 	- Truncate the MAC to, say, 4 bytes.  Yes, a simple brute
> 		force attack lets one forge so short a MAC - but
> 		is such an attack practically mountable in real
> 		time by attackers who concern you?

In fact, 32-bit authentication tags are a feature of
SRTP (RFC 3711). 



> 	- Even simpler, send only one MAC every second - i.e.,
> 		every 50 packets, for the assumed parameters.
> 		Yes, an attacker can insert a second's worth
> 		of false audio - after which he's caught.  I
> 		suppose one could come up with scenarios in
> 		which that matters - but they are very specialized.
> 		VOIP is for talking to human beings, and for
> 		human beings in all but extraordinary circumstances
> 		a second is a very short time.

Not sending a MAC on every packet has difficult interactions with
packet loss. If you do the naive thing and every N packets send a MAC
covering the previous N packets, then if you lose even one of those
packets you can't verify the MAC. But since some packet loss is
normal, an attacker can cover their tracks simply by removing one out
of every N packets.

Since (by definition) you don't have a copy of the packet you've lost,
you need a MAC that survives that--and is still compact. This makes
life rather more complicated. I'm not up on the most recent lossy
MACing literature, but I'm unaware of any computationally efficient
technique which has a MAC of the same size with a similar security
level. (There's an inefficient technique of having the MAC cover
all 2^50 combinations of packet loss, but that's both prohibitively
expensive and loses you significant security.)


> The NSA quote someone - Steve Bellovin? - has repeated comes to mind:
> Amateurs talk about algorithms.  Professionals talk about economics.
> Using DTLS for VOIP provides you with an extremely high level of
> security, but costs you 50% packet overhead.  Is that worth it to you?
> It really depends - and making an intelligent choice requires that
> various alternatives along the cost/safety curve actually be available.

Which there are, as indicated above and in my previous message. 

-Ekr



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