[VOIPSEC] Watering down VoIP security expectations.

[Dustin D. Trammell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Horne wrote:
> In someways, I think the VoIP (and security especially) industry, aside 
> from the hype, is actually devolving (going backwards) and settling for 
> solutions just years before we would of thought as "not good enough". I 
> think there needs to be a wholesale review on WTF are we doing and where 
> are we going because it seem to me that there is a "kinda maybe" solution 
> for this and a "kinda maybe" solution for that and no wholistic approach to 
> the security issue. Maybe we do need to go "back to school" on VoIP 
> security and reassess the protocols and (re)incorporate new ideas (backward 
> interoperable if possible) and not take an after thought "I got this cool 
> VoIP phone now how do I secure it" approach which we have today.

Since it seems others jumped on the "Solving SPIT" portion of your post,
I'll take a different route (:

I agree with the above sentiment completely.  I noticed much the same
thing back in August when I first began following this list.  Rather
than reiterate my commentary, I'll just link you to the rant on my blog:

   http://dtrammell.livejournal.com/941.html

In a nutshell, I think a lot of the half-solutions and compromises stem
from the effort to make everything backwards compatible in a sector full
of hardware devices that weren't designed (capacity wise) to support
major extended functionality like adding crypto (SRTP) after the fact,
so the consensus is that the solution must be able to fall back to
another (probably insecure) operational mode if it can't support the new
secure mode.  Guess which operational mode an attacker is going to try
to force the device into before/while attacking?

In my opinion, the VoIP industry is still in it's relative infancy; it
should be OK to leave some technology behind.  Not every solution needs
to be backward compatible.  It would be nice if it is, but it shouldn't
always be a requirement, and will most likely hinder the security the
solution is meant to provide.

- --
Dustin D. Trammell
Security Research
TippingPoint, a Division of 3Com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)

iD8DBQFEEbdGnCjPZ3weQjsRAiFRAJ452gDW7YgbGoUhVlNfqB9EzN9+SQCeMsI/
GOn4IceXdmVpvw/DiKtZpu4=
=1Mdw
-----END PGP SIGNATURE-----