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

[simon <simon mungewell org>]

On Wed, Sep 06, 2006 at 06:16:34PM +0200, Daniel Smertnig wrote:
> 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).

If presented with a 'non valid' SAS then what can the user/application
do????

Maybe the question should be along the lines 'Do you want to validate
peer?'.
---
'No' - continue call, but don't save persistant data... if a user wants
to hang up that is up to them.....  show broken padlock.
You may want to deliberately seed mis-information to your Man-in-the-Middle 
or shout out 'Prank Caller, Prank Caller').

'Yes' - continue call and save persistant data... show padlock
---

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

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


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

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.

The idea of having anything 'secure' running on Windows usually amuses
me....

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

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

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

> 
> > 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 ;-)

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.


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?

Simon.