[sip-comm-dev] ZRTP for one-way communication channels


#1

All,

after some tests I've checked in a modification that shall support
ZRTP for one-way RTP sessions (r5049). This option is enabled
for ZRTP multi-stream type sessions only. In case of SC this would
be the video stream.

Thus if one party has video equipment and the other party does not
have such hardware then the one-way video stream will be secure.

Romain, can you test this feature with your setup? Thanks.

Regards,
Werner

···

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


#2

Hi Werner,

It seems that your latest commit brings some issues. Video is actually completely disabled in p2p calls if one of the peer does not have a camera. It works however if both peers have a camera. Any idea of what could cause the problem?

More general thoughts below.

after some tests I've checked in a modification that shall support
ZRTP for one-way RTP sessions (r5049). This option is enabled
for ZRTP multi-stream type sessions only.

After reading the whole thread, it seems there are two points of view here: "all or nothing" and "few security is better than nothing". I think both opinions make sense, according to the people we target. People that do not have any security notions will anyway send whatever they like through their communication channel. In that case it may be better to have something a bit secured even though it could be compromised easily. On the other side, leaving such possibility may give the feeling to other users that the channel is really secured (though we clearly advertise it through notifications... but who reads them anyway :slight_smile:

So what I would suggest is to have a configuration checkbox that would allow users to choose whether they want to secure one-way RTP sessions for non-multistream type sessions. Whether this would be enabled/disabled by default is another story, but at least this would give the choice to the users. WDYT?

Cheers,
romain

···

On 2009/02/21, at 12:22, Werner Dittmann wrote:

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


#3

Romain,

Romain KUNTZ schrieb:

Hi Werner,

It seems that your latest commit brings some issues. Video is actually
completely disabled in p2p calls if one of the peer does not have a
camera. It works however if both peers have a camera. Any idea of what
could cause the problem?

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

More general thoughts below.

after some tests I've checked in a modification that shall support
ZRTP for one-way RTP sessions (r5049). This option is enabled
for ZRTP multi-stream type sessions only.

After reading the whole thread, it seems there are two points of view
here: "all or nothing" and "few security is better than nothing". I
think both opinions make sense, according to the people we target.
People that do not have any security notions will anyway send whatever
they like through their communication channel. In that case it may be
better to have something a bit secured even though it could be
compromised easily. On the other side, leaving such possibility may give
the feeling to other users that the channel is really secured (though we
clearly advertise it through notifications... but who reads them anyway :slight_smile:

So what I would suggest is to have a configuration checkbox that would
allow users to choose whether they want to secure one-way RTP sessions
for non-multistream type sessions. Whether this would be
enabled/disabled by default is another story, but at least this would
give the choice to the users. WDYT?

Yes, this would be the best way to solve it IMHO. Those who know what they
are dowing can switch it on, the "ordinary" user would (should) not touch
it. Thus my proposal: default off :wink:

Regards,
Werner

···

On 2009/02/21, at 12:22, Werner Dittmann wrote:

---------------------------------------------------------------------
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 Werner,

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

The problem persists after damencho's latest commit. Please find enclosed the logs & trace of a p2p call done with r5058.

Yes, this would be the best way to solve it IMHO. Those who know what they
are dowing can switch it on, the "ordinary" user would (should) not touch
it. Thus my proposal: default off :wink:

Seems like we are going toward a consensus :slight_smile:

Cheers,
romain

sip-communicator0.log.0 (170 KB)

sc.pcap (236 KB)

···

On 2009/02/23, at 17:47, Werner Dittmann wrote:


#5

Hi all,

Sorry to join the debate late. I hope it's still open though :wink:

In brief, I would propose to:
- always enable ZRTP if possible
- properly inform the user in the GUI about the requirements for a
   better security if it's not already done
- and_that's_it, no new option whatsoever

From my understanding of ZRTP, it relies on both parties to check one

another displayed SAS to assume a session is secure with high
probability. By which mean users communicate the SAS is their choice.
Our responsability is only to make sure they're well aware that the
transmission of the SAS should be encrypted and preferably
authenticated, should it be with a ZRTP audio session or any other
protocol SC might not even know of (eg Voice over Air).

In the end, we can *never* assert that the SAS was successfully checked,
just hope the user followed our advice. That's why it would make sense
for the media package not to take any decision about enabling ZRTP based
on assumptions like "ok, we had a two-way ZRTP audio prior to this new
single-way video stream, so the nice users who probably had no other
mean but using the audio ZRTP to check the SAS actually probably did".
Why not just go with the human factor, and enable ZRTP whenever
supported?

IMHO our role should be restricted to giving accurate and visible
information to the user, ie address the problem in the GUI if needed.
Enabling ZRTP by default alone will never create a false sense a
security, but telling users that their conversation is secure when we
are not sure of it sure will.

Cheers,

···

--
Sébastien Mazy

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


#6

Romain,

can you re-send the sc.pcap please? I inadvertently deleted the
file.

What I can see from the log: the video channel is enabled but
somehow the packets are not processed correctly.

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Werner,

On 2009/02/23, at 17:47, Werner Dittmann wrote:

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

The problem persists after damencho's latest commit. Please find
enclosed the logs & trace of a p2p call done with r5058.

Yes, this would be the best way to solve it IMHO. Those who know what
they
are dowing can switch it on, the "ordinary" user would (should) not touch
it. Thus my proposal: default off :wink:

Seems like we are going toward a consensus :slight_smile:

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

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


#7

Hi Werner,

I'll send it to you in private.

Cheers,
romain

···

On 2009/02/24, at 7:47, Werner Dittmann wrote:

Romain,

can you re-send the sc.pcap please? I inadvertently deleted the
file.

What I can see from the log: the video channel is enabled but
somehow the packets are not processed correctly.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

On 2009/02/23, at 17:47, Werner Dittmann wrote:

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

The problem persists after damencho's latest commit. Please find
enclosed the logs & trace of a p2p call done with r5058.

Yes, this would be the best way to solve it IMHO. Those who know what
they
are dowing can switch it on, the "ordinary" user would (should) not touch
it. Thus my proposal: default off :wink:

Seems like we are going toward a consensus :slight_smile:

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

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


#8

Romain,

the cause is quite simple. The SIP responder (the one which
sends the 200 OK) does not offer _any_ video support, audio only.
Thus no party will send video packets.

The system at address 130.79.91.13 answers with 200 OK but the
SDP inside offers audio only. You may have a look at lines 1 and
19 of the PCAP file using wireshark.

It seems that this system is not able to decode video (missing
video library? Wrong initialization?) and thus does not include
a video offer in the SDP - even not a "recvonly".

Regards,
Werner

Romain KUNTZ schrieb:

···

Hi Werner,

I'll send it to you in private.

Cheers,
romain

On 2009/02/24, at 7:47, Werner Dittmann wrote:

Romain,

can you re-send the sc.pcap please? I inadvertently deleted the
file.

What I can see from the log: the video channel is enabled but
somehow the packets are not processed correctly.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

On 2009/02/23, at 17:47, Werner Dittmann wrote:

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

The problem persists after damencho's latest commit. Please find
enclosed the logs & trace of a p2p call done with r5058.

Yes, this would be the best way to solve it IMHO. Those who know what
they
are dowing can switch it on, the "ordinary" user would (should) not
touch
it. Thus my proposal: default off :wink:

Seems like we are going toward a consensus :slight_smile:

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

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

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


#9

Hi Werner,

It seems that this system is not able to decode video (missing
video library? Wrong initialization?) and thus does not include
a video offer in the SDP - even not a "recvonly".

Thanks for your detailed comment. I may have blame ZRTP a bit too fast, sorry for that :slight_smile:
Actually it worked fine on the same environment a few days ago, so I've filed an issue for this entry and attached the pcap and logs to the issue entry.

Maybe some other people dealing with the video part might want to take a look at this?
I can provide more logs/dumps from my environment if needed.

Cheers,
romain

···

On 2009/02/24, at 19:42, Werner Dittmann wrote:

Romain KUNTZ schrieb:

Hi Werner,

I'll send it to you in private.

Cheers,
romain

On 2009/02/24, at 7:47, Werner Dittmann wrote:

Romain,

can you re-send the sc.pcap please? I inadvertently deleted the
file.

What I can see from the log: the video channel is enabled but
somehow the packets are not processed correctly.

Regards,
Werner

Romain KUNTZ schrieb:

Hi Werner,

On 2009/02/23, at 17:47, Werner Dittmann wrote:

If the problem persists can you please enable logging for the usual
transformer stuff? In addition I would appreciate a Wireshark trace
if this is possible.

The problem persists after damencho's latest commit. Please find
enclosed the logs & trace of a p2p call done with r5058.

Yes, this would be the best way to solve it IMHO. Those who know what
they
are dowing can switch it on, the "ordinary" user would (should) not
touch
it. Thus my proposal: default off :wink:

Seems like we are going toward a consensus :slight_smile:

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

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

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