Re: ZRTP, Key Continuity, and bump in the stack

Craig Southeren <craigs@xxxxxxxxxxxxxxxxx> writes:
>> The basis of this attack is that in a bump-in-the-stack impl.,
>> there's no mechanical way to verify that the identities at
>> these two layers match. This allows a substitution attack between
>> any two people who are in your authentication cache. The upshot
>> is that bump-in-the-stack impls. aren't really safe...
>
>Accepting any legal ZID in the cache when negotiating a call is a very
>naive approach. I think it's reasonable to for Alice to assume that Bob
>will use the same ZID every time they talk. If the ZID changes, then
>this should be confirmed by the user in the same way that a cert change
>would be confirmed.

But isn't it the case for pure bump-in-the-wire case that "If the ZID
changes" can't be checked by the ZRTP code - the user has to verify it
on every call.

>I wasn't able to find any mention of this in the ZRTP draft - I think it
>probably should be mentioned.

Definitely!  Though this does cause issues with the classic
non-crypto-aware user reactions (i.e. click "Ok" on any random "is this
ok?" requester, and if possible click "don't bother me with this again").

>To be extra safe you can use different ZIDs for every remote party as
>described in 5.9 of the ZRTP draft. 

Does this help in the case of bump-in-the-wire?  I don't think so...

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@xxxxxxxxx
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
                - James Madison, 4th US president (1751-1836)