[jitsi~svn:9638] Modify text of security labels to include ciper information.


#1

Hi Emil, Yana,

this is a continuation of a private discussion on the list.

Hey Werner,

I've checked the information that Jitsi displays in the call info frame and
it just displays which type of key exchange protocol was used, for example
SDES, ZRTP. It does not show the details that I intend to display together
with the security icon. The details may become more important in case the
call is routed via ZRTP's "trusted PBX feature". This would be indicated in
the details. FreeSwitch already implements this feature and Jitsi can deal
with it, at least as a "passive" client because Jitsi has no GUI yet to handle
the "client enrollment" process.

Oh ... While Vincent and Yana were working on this, we definitely had a
discussion on the subject and I thought we agreed to add it there but I
am apparently mistaken.

Sorry about that.

Well, that's how development works :slight_smile: .

Thus a short question: shall I leave this information as part of the security icon
(easy) or shall we enhance the mechansims to show this detail also in the call
info frame. This change would require some serious modifications in
"*.service.protocol.media.MediaHandler" and the CallInfoFrame.

The idea was that the call window should look as simple as possible and
that we should really avoid adding there things that would just seem
cryptic to most users. Unfortunately the ciphers kind of fit that
description.

The Call Info Frame on the other hand is meant exactly for this:
providing important technical call details for experienced users and
experts.

Right. It provides a lot of information that comes in handy in cases of
low network quality for example.

I am not sure however why moving it from one part of the GUI to another
would require modifying the media service. We should probably discuss
this on but would you mind if we continue on "dev" so that the others
could also follow?

Done. The issue about the MediaHandler: The CallInfoFrame calls a method
in MediaHandler to get information about the crypto stuff. This MediHandler
method just returns an Enumeration that shows which key exchange was used.
The CallInfoFrame uses the Enumeration toString() the get the name and
displays it.

Thus the MediaHandler and CallInfoFrame must be enhanced to deal with
additional information. Here my proposal:

- modify the MediHandler.getEncryptionMethod(...) to return a String, not
  only the Enumeration. This string shall contain all necessary information.
  MediaHandler.getEncryptionMethod(...) can get the necessary information
  via the control structures. The getCipher is available for ZRTP :slight_smile: .
  Just as a question here: does SDES have similar information available that
  could/should be shown in CallInfoFrame?

- modify CallInfoFrame to accept a String (or null) as return value and
  use it - this is a very small change.

If you don't mind I will do these modifications and give it a try.

Regards,
Werner

···

Am 15.06.2012 22:49, schrieb Emil Ivov:

On 15.06.12 10:13, Werner Dittmann wrote:

Thanks,
Emil

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#2

Hey

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

[...]

I am not sure however why moving it from one part of the GUI to another
would require modifying the media service. We should probably discuss
this on but would you mind if we continue on "dev" so that the others
could also follow?

Done. The issue about the MediaHandler: The CallInfoFrame calls a method
in MediaHandler to get information about the crypto stuff. This

MediHandler

method just returns an Enumeration that shows which key exchange was used.
The CallInfoFrame uses the Enumeration toString() the get the name and
displays it.

Thus the MediaHandler and CallInfoFrame must be enhanced to deal with
additional information. Here my proposal:

- modify the MediHandler.getEncryptionMethod(...) to return a String, not
  only the Enumeration. This string shall contain all necessary

information.

  MediaHandler.getEncryptionMethod(...) can get the necessary information
  via the control structures. The getCipher is available for ZRTP :slight_smile: .
  Just as a question here: does SDES have similar information available

that

  could/should be shown in CallInfoFrame?

SDES uses a cipher/hash-combination out of set of pre-defined cipher suites
that could be shown (e.g. AES_CM_128_HMAC_SHA1_80). But in contrast to ZRTP,
the send and receive streams could use different suites. The name would be
available through
SDesControl.get(In|Out)Attribute().getCryptoSuite().encode()

- modify CallInfoFrame to accept a String (or null) as return value and
  use it - this is a very small change.

I don't like the idea of preparing strings for the UI in the MediaHandler
layer. IMO a better approach would be to return the SrtpControl instance (or
null for the matter) and let the CallInfoFrame decide what to do with it.
Just like we do it with the SecurityPanel in the call dialog.

I know about the objections about coupling the UI to neomedia and worse to
associated libraries. The MVVM pattern is what comes to mind if I think
about solving that twist.

If you don't mind I will do these modifications and give it a try.

Regards,
Werner

Thanks,
Emil

Regards,
Ingo

···

On 15.06.12 10:13, Werner Dittmann wrote:


#3

Hi Emil, Yana,

this is a continuation of a private discussion on the list.

...

Done. The issue about the MediaHandler: The CallInfoFrame calls a method
in MediaHandler to get information about the crypto stuff. This MediHandler
method just returns an Enumeration that shows which key exchange was used.
The CallInfoFrame uses the Enumeration toString() the get the name and
displays it.

Thus the MediaHandler and CallInfoFrame must be enhanced to deal with
additional information. Here my proposal:

- modify the MediHandler.getEncryptionMethod(...) to return a String, not
  only the Enumeration. This string shall contain all necessary information.
  MediaHandler.getEncryptionMethod(...) can get the necessary information
  via the control structures. The getCipher is available for ZRTP :slight_smile: .
  Just as a question here: does SDES have similar information available that
  could/should be shown in CallInfoFrame?

- modify CallInfoFrame to accept a String (or null) as return value and
  use it - this is a very small change.

If you don't mind I will do these modifications and give it a try.

Attached a screenshot with the Info frame and the ZRTP cipher details.

Werner

···

Am 16.06.2012 08:59, schrieb Werner Dittmann:

Regards,
Werner

Thanks,
Emil

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#4

Hey

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

[...]

SDES uses a cipher/hash-combination out of set of pre-defined cipher suites
that could be shown (e.g. AES_CM_128_HMAC_SHA1_80). But in contrast to ZRTP,
the send and receive streams could use different suites. The name would be
available through
SDesControl.get(In|Out)Attribute().getCryptoSuite().encode()

I'll have a look

- modify CallInfoFrame to accept a String (or null) as return value and
  use it - this is a very small change.

I don't like the idea of preparing strings for the UI in the MediaHandler
layer. IMO a better approach would be to return the SrtpControl instance (or
null for the matter) and let the CallInfoFrame decide what to do with it.
Just like we do it with the SecurityPanel in the call dialog.

Need to check if this is possible because the SrtpControl is not known to the
CallInfoFrame. To enable CallInfoFrame to get the information MediaHandler
must provide a public method to export the SrtpControl array and
CallInfoFrame has to repeat some actions performed in MediaHandler

I know about the objections about coupling the UI to neomedia and worse to
associated libraries. The MVVM pattern is what comes to mind if I think
about solving that twist.

If you don't mind I will do these modifications and give it a try.

Regards,
Werner

Thanks,
Emil

Regards,
Ingo

Regards,
Werner

···

Am 16.06.2012 12:35, schrieb Ingo Bauersachs:

On 15.06.12 10:13, Werner Dittmann wrote:

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#5

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Need to check if this is possible because the SrtpControl is not known to

the

CallInfoFrame. To enable CallInfoFrame to get the information MediaHandler
must provide a public method to export the SrtpControl array and
CallInfoFrame has to repeat some actions performed in MediaHandler

Instead of returning the SrtpControlType, just return the actual
SrtpControl. No need to return the whole list of possible controls. The
current getEncryptionMethod() is AFAIK only used by the CallInfoFrame, so
you could drop/refactor that.

Regards,
Ingo


#6

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Need to check if this is possible because the SrtpControl is not known to

the

CallInfoFrame. To enable CallInfoFrame to get the information MediaHandler
must provide a public method to export the SrtpControl array and
CallInfoFrame has to repeat some actions performed in MediaHandler

Instead of returning the SrtpControlType, just return the actual
SrtpControl. No need to return the whole list of possible controls. The
current getEncryptionMethod() is AFAIK only used by the CallInfoFrame, so
you could drop/refactor that.

The SrtpControl does not carry it's own type (SDES, ZRTP. MIKEY) thus we always
need to perform the checks via "instanceof" - a method which I personally
don't like. Thus CallInfoFrame must check which type of SrtpControl was returned
using instanceof and then perform the string construction.

Just as a side note:
It seems the SrtpControl / ZrtpControl interfaces and associated implementations
are a bit "out-of-control" :slight_smile: . The SrtpControl I/F for example defines
methods that are not required by Sdes, but only by ZRTP. On the other hand
SdesControl implements public methods which are not reflected in SrtpControl I/F.

IMHO SrtpControl should be the superinterface (or grouping interface) for ZrtpControl,
(the missing) "SdesControl", (or MikeyControl, or ...). And I would add a
getSrtpControlType to the I/F :wink: .

Regards,
Werner

···

Am 16.06.2012 13:32, schrieb Ingo Bauersachs:

Regards,
Ingo

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#7

The SrtpControl does not carry it's own type (SDES, ZRTP. MIKEY) thus we
always need to perform the checks via "instanceof" - a method which I
personally don't like. Thus CallInfoFrame must check which type of
SrtpControl was returned using instanceof and then perform the string
construction.

Just as a side note: It seems the SrtpControl / ZrtpControl interfaces
and associated implementations are a bit "out-of-control" :slight_smile: . The
SrtpControl I/F for example defines methods that are not required by
Sdes, but only by ZRTP. On the other hand SdesControl implements public
methods which are not reflected in SrtpControl I/F.

Well, that might be because ZRTP was the first citizen and I adapted the
former ZrtpControl to SrtpControl just the way it seemed reasonable when I
integrated SDES. All of the methods defined in SrtpControl are somewhere
required for one of the encryption methods. I didn't want the neomedia code
to make any more distinguishing than absolutely necessary, that's why
SrtpControl maybe is a bit too "ZRTPish".

IMHO SrtpControl should be the superinterface (or grouping interface)
for ZrtpControl, (the missing) "SdesControl", (or MikeyControl, or ...).
And I would add a getSrtpControlType to the I/F :wink: .

SDesControl does exist, and SrtpControl IS the superinterface (and
MikeyControl also exists somewhere buried in my branches :-)). What did I
miss here?
I like the idea of the getControlType(), indeed better than the instanceof
checks.

Ingo