[sip-comm-dev] ZRTP GUI elements, SecureEvent problem and Default Encryption patch


#1

Hello all,

I'll try to cover three topics in this mail, two of them being discussed this week on the dev list.

1. First of all, related to the ZRTP label and button access from SCCallback (in the media bundle). I'll explain one more time very shortly the general idea behind implementing it like this (described in detail one or two times in the GSoC activity logs and I think also in some the mails sent some time ago):

   The security related elements defined in the GUI bundle are in essence general security elements which may be used by various security algorithms. Therefore the reduced functionality contained in the GUI bundle. ZRTP is an instance, let's say, of such a security algorithm which uses the GUI elements in it's own particular way according to the ZRTP4J UserCallback support which is extended through the SCCallback class. Practically, when ZRTP is used for securing it just "gets" the secure GUI elements it needs from the GUI bundle and uses them afterwards in the SCCallback class. Let's say, hypothetically, that at some moment in the future we will have another type of key management protocol implemented in SC, which will have it's own way of using the secure GUI elements, and will function at the signaling level, not at the media one like ZRTP. That protocol, in case of it's selection for securing will "get" the secure GUI elements like ZRTP does, from the GUI bundle, through the Call which is currently used to provide them, and will handle the button, label and maybe other elements associated with the current Call in other specific way than ZRTP does, probably in it's own Callback class.
To summarize, the idea was to make a set of general GUI secure elements instances for one call, specific to the key management used for the respective call - the button and label "become" ZRTP button and ZRTP label (regarding the functionality) after they are got inside the SCCallback.

I agree that this may not be the best approach, but in order to maintain the whole idea and to move the functionality in the GUI bundle if it's necessary, I must give some serious thought on how to change the implementation. I'm very short on time lately being involved in lots of activities (including a lab teaching assistant position) for this semester at my faculty, but I'll eventually try to find some free hours to think on Emil's ideas.

2. Related to the problem mentioned this week regarding the CallSessionImpl reference inside the SecureEvent, thanks to Lubomir for taking care of it. Also the location of the SecureEvent would be as suggested more appropriate in service.protocol.event than in service.protocol . Sorry for these mistakes. These appeared due to a late refactoring of some sources I made in order to rearrange some of them. I've changed the location of both the SecureEvent and SecureEventListener as an additional fix inside the patch discussed below.

3. As Werner suggested almost two weeks ago as I remember, I've tried to add the option for default securing = the user sets the default call encryption at the account creation inside the SIP account registration wizard through a checkbox, and call securing is activated by default without needing to press the button anymore. The patch attached adds this functionality. It seems to work well at the first sight. However I probably must make some more tests and revise some pieces of the other securing related code to be sure I didn't miss something.

Regards,
Emanuel

defaultencryption.patch (22 KB)


#2

Emanuel,

I certainly speak for myself and not for the SIP Communicator
community and I don't mean to take value away from your contribution
but to just shorten the time between patch submission and application.
The patch you've provided contains work on at least two of the
unrelated issues you've described in your e-mail. I feel it would've
been much easier to review the contribution and apply as much of it as
possible if it was broken in multiple patches with each patch dealing
with a single issue. For example, I could've applied the moving of the
SecureEvent and SecureListener to the .event package if it was in its
own patch.

Thank you,
Lubo

···

On Sat, Oct 18, 2008 at 7:33 PM, Onica S. Emanuel <eonica@info.uaic.ro> wrote:

Hello all,

I'll try to cover three topics in this mail, two of them being discussed
this week on the dev list.

1. First of all, related to the ZRTP label and button access from SCCallback
(in the media bundle). I'll explain one more time very shortly the general
idea behind implementing it like this (described in detail one or two times
in the GSoC activity logs and I think also in some the mails sent some time
ago):

The security related elements defined in the GUI bundle are in essence
general security elements which may be used by various security algorithms.
Therefore the reduced functionality contained in the GUI bundle. ZRTP is an
instance, let's say, of such a security algorithm which uses the GUI
elements in it's own particular way according to the ZRTP4J UserCallback
support which is extended through the SCCallback class. Practically, when
ZRTP is used for securing it just "gets" the secure GUI elements it needs
from the GUI bundle and uses them afterwards in the SCCallback class. Let's
say, hypothetically, that at some moment in the future we will have another
type of key management protocol implemented in SC, which will have it's own
way of using the secure GUI elements, and will function at the signaling
level, not at the media one like ZRTP. That protocol, in case of it's
selection for securing will "get" the secure GUI elements like ZRTP does,
from the GUI bundle, through the Call which is currently used to provide
them, and will handle the button, label and maybe other elements associated
with the current Call in other specific way than ZRTP does, probably in it's
own Callback class.
To summarize, the idea was to make a set of general GUI secure elements
instances for one call, specific to the key management used for the
respective call - the button and label "become" ZRTP button and ZRTP label
(regarding the functionality) after they are got inside the SCCallback.

I agree that this may not be the best approach, but in order to maintain the
whole idea and to move the functionality in the GUI bundle if it's
necessary, I must give some serious thought on how to change the
implementation. I'm very short on time lately being involved in lots of
activities (including a lab teaching assistant position) for this semester
at my faculty, but I'll eventually try to find some free hours to think on
Emil's ideas.

2. Related to the problem mentioned this week regarding the CallSessionImpl
reference inside the SecureEvent, thanks to Lubomir for taking care of it.
Also the location of the SecureEvent would be as suggested more appropriate
in service.protocol.event than in service.protocol . Sorry for these
mistakes. These appeared due to a late refactoring of some sources I made in
order to rearrange some of them. I've changed the location of both the
SecureEvent and SecureEventListener as an additional fix inside the patch
discussed below.

3. As Werner suggested almost two weeks ago as I remember, I've tried to add
the option for default securing = the user sets the default call encryption
at the account creation inside the SIP account registration wizard through a
checkbox, and call securing is activated by default without needing to press
the button anymore. The patch attached adds this functionality. It seems to
work well at the first sight. However I probably must make some more tests
and revise some pieces of the other securing related code to be sure I
didn't miss something.

Regards,
Emanuel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Emanuel,

Onica S. Emanuel написа:

Hello all,

I'll try to cover three topics in this mail, two of them being discussed
this week on the dev list.

1. First of all, related to the ZRTP label and button access from
SCCallback (in the media bundle). I'll explain one more time

Thanks!

very shortly

That's a good point actually. The shorter you keep your mails the more
it is likely that people would actually read and remember them.

the general idea behind implementing it like this (described in detail one
or two times in the GSoC activity logs and I think also in some the mails
sent some time ago):

I can understand why you would feel frustrated and if you think that any
of your previous posts is addressing these exact questions, then you
should definitely post a link to them. Keep in mind, however, that most
of the developers that are working on the zRTP integration are doing it
on a voluntary basis just as you are. We have a relatively active list
so it is quite natural that people would not always follow all threads
in detail.

   The security related elements defined in the GUI bundle are in essence
general security elements which may be used by various security
algorithms. Therefore the reduced functionality contained in the GUI
bundle. ZRTP is an instance, let's say, of such a security algorithm which
uses the GUI elements in it's own particular way according to the ZRTP4J
UserCallback support which is extended through the SCCallback class.
Practically, when ZRTP is used for securing it just "gets" the secure GUI
elements it needs from the GUI bundle and uses them afterwards in the
SCCallback class. Let's say, hypothetically, that at some moment in the
future we will have another type of key management protocol implemented in
SC, which will have it's own way of using the secure GUI elements, and
will function at the signaling level, not at the media one like ZRTP. That
protocol, in case of it's selection for securing will "get" the secure GUI
elements like ZRTP does, from the GUI bundle, through the Call which is
currently used to provide them, and will handle the button, label and
maybe other elements associated with the current Call in other specific
way than ZRTP does, probably in it's own Callback class.
To summarize, the idea was to make a set of general GUI secure elements
instances for one call, specific to the key management used for the
respective call - the button and label "become" ZRTP button and ZRTP label
(regarding the functionality) after they are got inside the SCCallback.

This does make sense. The problem is that it simply follows a different
notification model than the one we currently use between the UI media
and protocol provider services. All interaction between the UI and the
media bundle is currently happening through the protocol provider
service. Making the Media service interact with the UI therefore adds a
second notification channel.

I agree that this may not be the best approach, but in order to maintain
the whole idea and to move the functionality in the GUI bundle if it's
necessary, I must give some serious thought on how to change the
implementation. I'm very short on time lately being involved in lots of
activities (including a lab teaching assistant position) for this semester
at my faculty, but I'll eventually try to find some free hours to think on
Emil's ideas.

No worries. I'll try to handle it myself one of these days.

2. Related to the problem mentioned this week regarding the
CallSessionImpl reference inside the SecureEvent, thanks to Lubomir for
taking care of it. Also the location of the SecureEvent would be as
suggested more appropriate in service.protocol.event than in
service.protocol . Sorry for these mistakes. These appeared due to a late
refactoring of some sources I made in order to rearrange some of them.
I've changed the location of both the SecureEvent and SecureEventListener
as an additional fix inside the patch discussed below.

Thanks for sending these. We'll make sure they get on SVN. It would help
if you could split them in separate patches though. Lubo already
mentioned this and we also have a FAQ entry that addresses it:

http://www.sip-communicator.org/index.php/Documentation/FAQ#patch

3. As Werner suggested almost two weeks ago as I remember, I've tried to
add the option for default securing = the user sets the default call
encryption at the account creation inside the SIP account registration
wizard through a checkbox, and call securing is activated by default
without needing to press the button anymore. The patch attached adds this
functionality. It seems to work well at the first sight. However I
probably must make some more tests and revise some pieces of the other
securing related code to be sure I didn't miss something.

That's definitely useful, but I'd really prefer us to have stable basic
zRTP before thinking of any extra features.

Cheers
Emil

···

Regards,
Emanuel

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Emanuel,

···

On 2008/10/18, at 18:33, Onica S. Emanuel wrote:

3. As Werner suggested almost two weeks ago as I remember, I've tried to add the option for default securing = the user sets the default call encryption at the account creation inside the SIP account registration wizard through a checkbox, and call securing is activated by default without needing to press the button anymore. The patch attached adds this functionality. It seems to work well at the first sight. However I probably must make some more tests and revise some pieces of the other securing related code to be sure I didn't miss something.

That's a nice feature indeed, thanks! I will not commit it yet as we need to refactor some other parts as discussed in a previous mail, but I'll keep the patch in my files for a later commit.

Cheers,
romain

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hello,

Hey Emanuel,

Thanks!

very shortly

That's a good point actually. The shorter you keep your mails the more
it is likely that people would actually read and remember them.

Actually I'm sorry and I know that often I'm getting too long with my explanations. I just want too be sure that all is clear enough.

the general idea behind implementing it like this (described in detail one
or two times in the GSoC activity logs and I think also in some the mails
sent some time ago):

I can understand why you would feel frustrated and if you think that any
of your previous posts is addressing these exact questions, then you
should definitely post a link to them. Keep in mind, however, that most
of the developers that are working on the zRTP integration are doing it
on a voluntary basis just as you are. We have a relatively active list
so it is quite natural that people would not always follow all threads
in detail.

It wasn't any frustration there :slight_smile: I really didn't want to make it sound this way. I'm well aware of the things you mentioned and I don't find anything out of common of not following all threads in detail ( especially when they get as long as some of mine did :slight_smile: ). I've just wanted to point out that the whole idea can be found more detailed in previous posts if it wasn't clear enough (or complete) as I resumed it. I didn't give a specific link because all the GUI related part actually started earlier during GSoC and developed over time to get at the described point but also keeping some parts from previous versions (which are described in more than one place). The last detailed info about the GUI part can be found here : https://sip-communicator.dev.java.net/servlets/ReadMsg?listName=dev&msgNo=4444

2. Related to the problem mentioned this week regarding the
CallSessionImpl reference inside the SecureEvent, thanks to Lubomir for
taking care of it. Also the location of the SecureEvent would be as
suggested more appropriate in service.protocol.event than in
service.protocol . Sorry for these mistakes. These appeared due to a late
refactoring of some sources I made in order to rearrange some of them.
I've changed the location of both the SecureEvent and SecureEventListener
as an additional fix inside the patch discussed below.

Thanks for sending these. We'll make sure they get on SVN. It would help
if you could split them in separate patches though. Lubo already
mentioned this and we also have a FAQ entry that addresses it:

http://www.sip-communicator.org/index.php/Documentation/FAQ#patch

I'm very sorry for the inconvenience. I've attached to this mail another patch version which contains only the SecureEvent and SecureEventListener refactoring.

Regards,
Emanuel

SecureRefactoring.patch (6.91 KB)

···

On Sun, 19 Oct 2008, Emil Ivov wrote:


#6

Hi Emanuel,

Thank you for the contribution of the moving of SecureEvent and
SecureEventListener into the .service.protocol.event package. It's now
applied to trunk in r4605.

Regards,
Lubo

···

2. Related to the problem mentioned this week regarding the
CallSessionImpl reference inside the SecureEvent, thanks to Lubomir for
taking care of it. Also the location of the SecureEvent would be as
suggested more appropriate in service.protocol.event than in
service.protocol . Sorry for these mistakes. These appeared due to a late
refactoring of some sources I made in order to rearrange some of them.
I've changed the location of both the SecureEvent and SecureEventListener
as an additional fix inside the patch discussed below.

Thanks for sending these. We'll make sure they get on SVN. It would help
if you could split them in separate patches though. Lubo already
mentioned this and we also have a FAQ entry that addresses it:

http://www.sip-communicator.org/index.php/Documentation/FAQ#patch

I'm very sorry for the inconvenience. I've attached to this mail another
patch version which contains only the SecureEvent and SecureEventListener
refactoring.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net