Re: [Ekiga-devel-list] New features in CVS.

["Daniel Smertnig" <daniel smertnig gmail com>]

On 9/6/06, simon <simon mungewell org> wrote:
> If presented with a 'non valid' SAS then what can the user/application
> do????

'non valid' == audible verification turns up that the SAS are
different, this then triggers the usual security-alert message (i.e.
"Your connection may be under attack" or some other cool sounding
message, the user can then choose what should happen)

> Maybe the question should be along the lines 'Do you want to validate
> peer?'.
That would require a two step process -- first ask if the SAS should
be validated and then ask for the validation information, I think it
should be kept down to a single step/dialog.

> I was thinking that the idea of 'Check Again' is usefull as it incourages
> the checking of the SAS as a normal routine. Although this is not necessary
> on the second call to a partner, unless you are routinely clearing
> persistant data (in which case it would pop up the box anyhow).

Yeah, but it is unlikely that somebody would want to validate the SAS
every time. I think it would be better to provide some place in the UI
to call up the dialog again if someone wants to change his opinion.
However displaying the SAS when hovering over the padlock may become
useful if one of the parties forgets to check the SAS-flag or somehow
manages to clear it.

> I agree that the 'never check SAS' seems a bit pointless.... maybe in
> the config pages next to 'use ZRTP when available'. In which case the
> padlock chould just be shown good/broken depending on whether peer has
> been previously validated and clicking on it would open the 'validation
> window'.

Actually the padlock should not be show broken just because the SAS
has not been verified, after all ZRTP gives pretty strong security
even without ever validating the SAS. I would reserve the broken
padlock for
a) failed ZRTP negotiation although the other endpoint supports it (to
let the user know, might be a DoS on ZRTP)
and
b) a compromised session (e.g. known SAS mismatch) if the user chooses
to continue after an alert.

> Goes with the concept that you can't be confident that the device on the
> other end of conversation isn't hacked, or (comment below) happens to keep
> a record of the session keys which can be used for later decryption.
Yes, but that is outside of the scope of ZRTP -- if one of the
endpoints is compromised there are different ways to get at the data
easier, e.g. intercepting the decrypted RTP packets in memory,
intercepting the audio stream on it's way to the speakers, replacing
the softphone binary etc.

> OK I'm probably not understanding how the persistant data exists in the
> case of multiple endpoints (ie. Hard IP phone and Laptop softphone)
> registered to same VoIP account. If it is 'sip address'+'random ID'
> Ekiga would treat them as different 'people' and the use of one would
> not effect the persistant data of the other...

ZRTP is completely independent from the signalling layer, therefore it
also does not use sip-addresses to identify peers. It generates a
random 96-bit number, the ZID, to identify a peer. The specification
refers to one ZID per installation, which is generated at installation
time. I plan to generate it per system user, since otherwise you have
an implicit trust relationship between different users by the way of
the SAS-flags (i.e. if "user A" sets the SAS-flag "user B" would
automatically trust "user A" to have carried out the SAS
verification).

BTW, the signalling-agnostic design of ZRTP also allows it to be used for H.323.

> > > And along the same lines it would be nice to have a 'Clear Privacy Data'
> > > in much the same way that mozilla has (should clear the certs as well as
> > > the call logs).
> >
> > Hmm, I am not sure what this would be useful for.
>
> When the secret police kick down the door they don't have a record of
> who you have called in the past. Useful for activists in opressive
> regimes (and the Tin Foil Hat briggade).

Hmm, it should probably be added. But I think the police will have an
easier time just looking at your SIP/RTP traffic. To use the ZRTP
persistent data to reconstruct your connection they would probably
have to know both parties already and then match the ZIDs and shared
secrets found on both computers (they won't be able to map a ZID to an
SIP address).

> Stupid things happen. I was thinking that a 'good' approach to law
> enforcement would be to cut the power as they kick down the door.
> A full disk image (with swap file/partition) could be maintained and
> investigated later.

Yes, and having an encrypted swap is always a good idea, but Ekiga
will also do its best not to swap key data (e.g. via mlock(), since
Linux >= 2.6.9 that is also available to unprivileged users, Windows
also has VM-locking facilities IIRC).

> As a side note the ZPhone application has the ability to 'Go Clear' and
> 'Go Secure' - which I assume re-negoiates the RTP stream with or without
> ZRTP.
>
> Why would anyone want the ability to do this and do we need to have this
> functionality?

I don't think so (and I did not implement GoClear in my ZRTP
implementation). Besides cluttering the user interface and providing
an IMHO unnecessary feature (you could always switch of encryption via
the preferences if you do not want it), it is even hard to implement
(while the call is being cleared all RTP frames must either be queued
back or dropped).

--
Daniel