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

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

On 9/6/06, simon <simon mungewell org> wrote:
> Hi,
> Personally I prefer the 'buttons' one. The 'Ask again Later'
> should be a tick box and have an alternative location within the config so
> that it can be turned back on - maybe just when the padlock is clicked...

I don't think that will work since the Ask again later option is not
meant as an additional option to the buttons, but as a third
alternative, the user in theory has three alternatives:

- Confirm that the SAS was sucessfully compared.
- Tell the application that the SAS values are different (oops!).
- Do nothing in this session, and defer verification of the SAS to the
next session. If this were a check box the user would still be forced
to answer either "Yes" or "No", which is actually incorrect.
- Actually there would be a fourth option: never verify the SAS, but
since SAS verification is easy I don't think it should be there (if
it's wanted it could be a preference).

> Hovering over the padlock could 'pop up' the SAS.
Good idea.

> [Techically the SAS does not confirm that someone is not listening in (as
> they could steal the session key a different way and then be able to
> decode the ZRTP stream).... it prevents 'Man in the Middle' attacks.]

I know, but I want to explain it to the users without using too much
technical jargon, improved texts are welcome (probably "not
intercepted"?). BTW, if somebody has the ability to get your session
keys without mounting a MitM attack you're in serious trouble anyway,
encryption won't help you (or your peer) then ;-).

> You should also model the window which would appear if there is
> 'tampering' detected (partner cert does not match previous call etc).

I think a simple message box will suffice here.
For the exact details on how to handle "lost" shared secrets I'm
waiting for a newer ZRTP since the current one has some deficiencies
in this area (an active MitM can easily nullify shared-secrets because
the corresponding ID fields in the DHPart messages are not
authenticated, I hope this will be fixed).

> You may want 'Use Anyway' as they may be using a different computer from
> last time (maybe on vacation, etc) and you might want to keep the validation
> data for the next call with their normal set-up.

I don't think "Use Anyway" would be of any use, if the peer is using
another computer the ZID will (hopefully) be different. If he is using
his own profile/home directory then hopefully both the ZID and the
shared secrets are carried with him.

> 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.

> PS Never store the session key to disk!!!! and use an encrypted swap
> file ;-)

I'll probably keep the secrets (or at least those that persist to a
later session) in a mlock()ed page anyway. And I can't image why one
would store the session key to disk ;-)

--
Daniel