[VOIPSEC] Voipsec Digest, Vol 8, Issue 26

[Randell Jesup]

"Christopher A. Martin" <chris at InfraVAST.com> writes:
>And as was pointed out earlier in the thread by another person, the 
>delay is acceptable. People are becoming accustomed to delays, otherwise 
>cell phones would not be as popular as they are today.

        This is in no way close to acceptable in the marketplace.  The
general marketplace will choose no encryption over that sort of delay.
(And that would hurt the market and the users.)

        Cell phones don't have a long delay answering a call, which is what
we're talking about here.  For this sort of delay, you'd have to give an
audio tone once the connection was established to tell them they could
talk, and it would be horrible.

        Either we have to find a way to get the delay down to max couple
hundred ms, or go with a=crypto over TLS, or no security at all.

        One possible solution may be to say "if the endpoint is too slow,
it won't be able to do fast encryption setup".  I'm not sure what level of
processor/DSP that means for DH or other end-to-end solutions is - I know
the papers from Norway (sweden?) showed it was substantial delay on their
endpoint, which was either a circa 1Ghz PC or a Windows PDA I think.

        Another may be to bite the bullet and specify some form of PKI.
But we have to verify not on that the UA cert is a valid cert, but that
it's the valid cert for that UA - i.e. that it matches who we think we're
calling or we think called us; that it matches the caller info or the
number we dialed.  And matching against the number we dialed will be...
fun (not).  (Forking, forwarding, dialing rules/enum handled by the proxy/
server, etc).

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com