[sip-comm-dev] Re: svn commit: r5049 - ZRTPTransformEngine.java


#1

Hey Werner,

Thanks for taking care of this.

A quick note inline.

wernerd@dev.java.net wrote:

[snip]
Log:
Support one-way communication for ZRTP multi-stream type sessions.

Modified: trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=5049&p1=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&r1=5048&r2=5049

--- trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java 2009-02-21 11:17:06+0000

[snip]

@@ -552,7 +558,7 @@
          */
         if (!zPkt.isZrtpPacket())
         {
- if (!started && enableZrtp && sendPacketCount >= 1)
+ if (!started && enableZrtp && (multiStream || (sendPacketCount >= 1)))

The condition here is based on the assumption that the media package
would be aware of all communication channels that exist between the
participants. Leaving aside the argument about whether or not we should
encrypt sessions where SAS verification would not be possible, we should
probably not deny users the possibility to complete it through other
non-audio/video means such as OTR encrypted chat sessions, signed https
sites, ssh connections, etc.

I'd personally drop the (multiStream || (sendPacketCount >=1)) part. The
only guarantee it gives us is that sessions that don't have video and
only have uni-directional audio would have no way of being encrypted.

What do you think?

Emil

···

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


#2

Emil, Werner,

the applications that I know that are desired for one-way video
streams would need encryption. The SAS could be exchanged
via two-way audio.

For example, I am talking with someone on secure voice; he does
not have his cam connected, but I want to show my partner the
latest results of a confidential experiment by using my Webcam.
The one-way video must be encrypted.

Earl

Emil Ivov wrote:

···

Hey Werner,

Thanks for taking care of this.

A quick note inline.

wernerd@dev.java.net wrote:
  

[snip]
Log:
Support one-way communication for ZRTP multi-stream type sessions.

Modified: trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=5049&p1=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&r1=5048&r2=5049

--- trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java 2009-02-21 11:17:06+0000

[snip]

@@ -552,7 +558,7 @@
          */
         if (!zPkt.isZrtpPacket())
         {
- if (!started && enableZrtp && sendPacketCount >= 1)
+ if (!started && enableZrtp && (multiStream || (sendPacketCount >= 1)))
    
The condition here is based on the assumption that the media package
would be aware of all communication channels that exist between the
participants. Leaving aside the argument about whether or not we should
encrypt sessions where SAS verification would not be possible, we should
probably not deny users the possibility to complete it through other
non-audio/video means such as OTR encrypted chat sessions, signed https
sites, ssh connections, etc.

I'd personally drop the (multiStream || (sendPacketCount >=1)) part. The
only guarantee it gives us is that sessions that don't have video and
only have uni-directional audio would have no way of being encrypted.

What do you think?

Emil

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

Hi Emil,

I'm quite reluctant to offer one-way communication for all
sessions.

Just some notes about the security attributes of the SAS mechanism
that ZRTP uses and why ZRTP uses it in this way:

<quotes from ZRTP draft>
...
It uses ephemeral Diffie-Hellman (DH) with hash commitment, and
allows the detection of man-in-the-middle (MiTM) attacks by
displaying a short authentication string (SAS) for the users
to read and verbally compare over the phone.

...

The SAS is not treated as a secret value, but it must be compared to
see if it matches at both ends of the communications channel. The
two users read it aloud to their partners to see if it matches.
...
</quotes from ZRTP draft>

The main topic here is: "compare verbally" and "read it aloud". Why?
You need to hear your partner's voice to make sure that you've called
the right person. Then both partners compare the SAS, for example the
caller reads the first two characters, the called person reads the
second half of the SAS (instead of voice two-way video will do the same).

You should click "verify" only if you know the called person, can
safely identify him/her (either because you know the voice or some
other attributes) and correctly verify the SAS. ZRTP and its
security was designed around this "verbal comparison of SAS". Click
"verify" only if you know and trust the person. Never trust a SAS
comparison that was not given verbally (or using two-way video).

An attack against ZRTP exists. Phil calls it the "Rich Little Attack":

<quote from Zooko Wilcox-O'Hearn's blog>

Caveat: actually there is a safe state that the attacker can reach,
if they can reliably, in near-realtime, fake the victim's voices
doing the voice-authentication check. This is what Phil calls
"The Rich Little Attack". I believe that such an attack is
currently expensive (i.e. the most cost-effective way to do it
is probably to hire a talented human or several).

</quote from Zooko Wilcox-O'Hearn's blog>

To make a long story short: when comparing SAS and have some trust in
it you must be able to identify your communication partner.

Can this be done using OTR encrypted chats? I doubt it.
During a chat, even over encrypted OTR, the only thing you see is
some typed characters - who is typing the characters?

If OTR chats would provide such a safe identification then ZRTP is
not needed in the first place:
Setup an OTR encrypted chat, identify your partner, exchange some keys
and enter it as master keys for SRTP encryption - done. But how
do you identify your partner with sufficient certainty and trust?

The same holds true for the other ways you listed - all provide
ways to transmit data in encrypted form but _none_ of them provide
a way to actually identify the the person who is using it. This is why
ZRTP requires verbal (or two-way video) comparison of SAS to ensure
the right person is doing it.

Regards,
Werner

Emil Ivov schrieb:

···

Hey Werner,

Thanks for taking care of this.

A quick note inline.

wernerd@dev.java.net wrote:

[snip]
Log:
Support one-way communication for ZRTP multi-stream type sessions.

Modified: trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=5049&p1=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&r1=5048&r2=5049

--- trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java 2009-02-21 11:17:06+0000

[snip]

@@ -552,7 +558,7 @@
          */
         if (!zPkt.isZrtpPacket())
         {
- if (!started && enableZrtp && sendPacketCount >= 1)
+ if (!started && enableZrtp && (multiStream || (sendPacketCount >= 1)))

The condition here is based on the assumption that the media package
would be aware of all communication channels that exist between the
participants. Leaving aside the argument about whether or not we should
encrypt sessions where SAS verification would not be possible, we should
probably not deny users the possibility to complete it through other
non-audio/video means such as OTR encrypted chat sessions, signed https
sites, ssh connections, etc.

I'd personally drop the (multiStream || (sendPacketCount >=1)) part. The
only guarantee it gives us is that sessions that don't have video and
only have uni-directional audio would have no way of being encrypted.

What do you think?

Emil

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

Earl,

The scenario you describe would already work with the code that Werner
has committed. The point I was making concerns cases where people
communicate through multiple channels but only one of them is known the
SIP Communicator media bundle, and that channel happens to be
uni-directional.

One possible example could have one of the parties streaming video
content presumably containing confidential information and a
bi-directional OTR protected chat session (that could even be happening
through another client).

Cheers
Emil

Earl wrote:

···

Emil, Werner,

the applications that I know that are desired for one-way video
streams would need encryption. The SAS could be exchanged
via two-way audio.

For example, I am talking with someone on secure voice; he does
not have his cam connected, but I want to show my partner the
latest results of a confidential experiment by using my Webcam.
The one-way video must be encrypted.

Earl

Emil Ivov wrote:

Hey Werner,

Thanks for taking care of this.

A quick note inline.

wernerd@dev.java.net wrote:
  

[snip]
Log:
Support one-way communication for ZRTP multi-stream type sessions.

Modified: trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=5049&p1=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&r1=5048&r2=5049

--- trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java 2009-02-21 11:17:06+0000

[snip]

@@ -552,7 +558,7 @@
          */
         if (!zPkt.isZrtpPacket())
         {
- if (!started && enableZrtp && sendPacketCount >= 1)
+ if (!started && enableZrtp && (multiStream || (sendPacketCount >= 1)))
    

The condition here is based on the assumption that the media package
would be aware of all communication channels that exist between the
participants. Leaving aside the argument about whether or not we should
encrypt sessions where SAS verification would not be possible, we should
probably not deny users the possibility to complete it through other
non-audio/video means such as OTR encrypted chat sessions, signed https
sites, ssh connections, etc.

I'd personally drop the (multiStream || (sendPacketCount >=1)) part. The
only guarantee it gives us is that sessions that don't have video and
only have uni-directional audio would have no way of being encrypted.

What do you think?

Emil

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


#5

Hey Werner,

Werner Dittmann wrote:

Hi Emil,

I'm quite reluctant to offer one-way communication for all
sessions.

We are already doing this simply because we couldn't and shouldn't be
forcing the end of communication when encryption is not possible. I hope
we agree on this one.

The question is whether we will be forcing users to send their content
without any protection for such cases, or, alternatively, simply warn
them about the risks and do our best.

[snip]

An attack against ZRTP exists. Phil calls it the "Rich Little Attack":

Right. But the fact that the possibility of this attack exists does not
mean we should stop offering support for ZRTP. Besides we are not even
doing anything to warn our users against it inside the user interface
(and I am not saying we should). We are betting on the fact that it is
unlikely for such a thing to happen.

The situation is pretty much the same in cases where the SAS has not
been confirmed. Our responsibility ends with informing the user that
they are not completely protected.

Can this be done using OTR encrypted chats? I doubt it.
During a chat, even over encrypted OTR, the only thing you see is
some typed characters - who is typing the characters?

If OTR chats would provide such a safe identification then ZRTP is
not needed in the first place:
Setup an OTR encrypted chat, identify your partner, exchange some keys
and enter it as master keys for SRTP encryption - done. But how
do you identify your partner with sufficient certainty and trust?

The same holds true for the other ways you listed - all provide
ways to transmit data in encrypted form but _none_ of them provide
a way to actually identify the the person who is using it. This is why
ZRTP requires verbal (or two-way video) comparison of SAS to ensure
the right person is doing it.

Well, how about ZRTP through another application, then? Or, how about an
old-fashioned direct, conversation between the two participants who may
happen to be within talking distance? There are probably many other
examples of ways to communicate and verify SASs that could be considered
equally or more secure than ZRTP.

Anyways, I shouldn't have headed down this path in the first place. The
main reason why we should start the encryption even when we are not
aware of a channel that could be used for secure authentication, is
simply the fact that taking your chances against a MITM attack is still
far better than transmitting with no encryption and exposing yourself to
a number of other potential risks ... including of course the man in the
middle attack.

Am I making more sense now?

Cheers
Emil

···

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


#6

This turned into a very interesting discussion, too tempting to just
keep lurking :wink:

Even if verbal verification if probably the main characteristic of ZRTP,
it is not the only way for protecting from MiTM attacks. For example,
sections 7.2 and 8.1.1 in draft-*-zrtp-14 offer alternative mechanisms
which apply also to one-way channels. Or am I missing something?

Enrico

Werner Dittmann wrote:

···

Hi Emil,

I'm quite reluctant to offer one-way communication for all
sessions.

Just some notes about the security attributes of the SAS mechanism
that ZRTP uses and why ZRTP uses it in this way:

<quotes from ZRTP draft>
...
It uses ephemeral Diffie-Hellman (DH) with hash commitment, and
allows the detection of man-in-the-middle (MiTM) attacks by
displaying a short authentication string (SAS) for the users
to read and verbally compare over the phone.

...

The SAS is not treated as a secret value, but it must be compared to
see if it matches at both ends of the communications channel. The
two users read it aloud to their partners to see if it matches.
...
</quotes from ZRTP draft>

The main topic here is: "compare verbally" and "read it aloud". Why?
You need to hear your partner's voice to make sure that you've called
the right person. Then both partners compare the SAS, for example the
caller reads the first two characters, the called person reads the
second half of the SAS (instead of voice two-way video will do the same).

You should click "verify" only if you know the called person, can
safely identify him/her (either because you know the voice or some
other attributes) and correctly verify the SAS. ZRTP and its
security was designed around this "verbal comparison of SAS". Click
"verify" only if you know and trust the person. Never trust a SAS
comparison that was not given verbally (or using two-way video).

An attack against ZRTP exists. Phil calls it the "Rich Little Attack":

<quote from Zooko Wilcox-O'Hearn's blog>

Caveat: actually there is a safe state that the attacker can reach,
if they can reliably, in near-realtime, fake the victim's voices
doing the voice-authentication check. This is what Phil calls
"The Rich Little Attack". I believe that such an attack is
currently expensive (i.e. the most cost-effective way to do it
is probably to hire a talented human or several).

</quote from Zooko Wilcox-O'Hearn's blog>

To make a long story short: when comparing SAS and have some trust in
it you must be able to identify your communication partner.

Can this be done using OTR encrypted chats? I doubt it.
During a chat, even over encrypted OTR, the only thing you see is
some typed characters - who is typing the characters?

If OTR chats would provide such a safe identification then ZRTP is
not needed in the first place:
Setup an OTR encrypted chat, identify your partner, exchange some keys
and enter it as master keys for SRTP encryption - done. But how
do you identify your partner with sufficient certainty and trust?

The same holds true for the other ways you listed - all provide
ways to transmit data in encrypted form but _none_ of them provide
a way to actually identify the the person who is using it. This is why
ZRTP requires verbal (or two-way video) comparison of SAS to ensure
the right person is doing it.

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

Thanks for taking care of this.

A quick note inline.

wernerd@dev.java.net wrote:

[snip]
Log:
Support one-way communication for ZRTP multi-stream type sessions.

Modified: trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java
Url: https://sip-communicator.dev.java.net/source/browse/sip-communicator/trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java?view=diff&rev=5049&p1=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&p2=trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java&r1=5048&r2=5049

--- trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java (original)
+++ trunk/src/net/java/sip/communicator/impl/media/transform/zrtp/ZRTPTransformEngine.java 2009-02-21 11:17:06+0000

[snip]

@@ -552,7 +558,7 @@
          */
         if (!zPkt.isZrtpPacket())
         {
- if (!started && enableZrtp && sendPacketCount >= 1)
+ if (!started && enableZrtp && (multiStream || (sendPacketCount >= 1)))

The condition here is based on the assumption that the media package
would be aware of all communication channels that exist between the
participants. Leaving aside the argument about whether or not we should
encrypt sessions where SAS verification would not be possible, we should
probably not deny users the possibility to complete it through other
non-audio/video means such as OTR encrypted chat sessions, signed https
sites, ssh connections, etc.

I'd personally drop the (multiStream || (sendPacketCount >=1)) part. The
only guarantee it gives us is that sessions that don't have video and
only have uni-directional audio would have no way of being encrypted.

What do you think?

Emil

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

Just a bit more precise :slight_smile: See inside.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Hi Emil,

I'm quite reluctant to offer one-way communication for all
sessions.

I'm quite reluctant to offer one-way communication for all
ZRTP sessions.

<SNIP --- SNAP>

An attack against ZRTP exists. Phil calls it the "Rich Little Attack":

Right. But the fact that the possibility of this attack exists does not
mean we should stop offering support for ZRTP. Besides we are not even
doing anything to warn our users against it inside the user interface
(and I am not saying we should). We are betting on the fact that it is
unlikely for such a thing to happen.

We have such a warning GUI in place. Currently it is implemented as
systray notification popup. If anything requires user attention then
we display a message and ask to user to take action.

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


#8

Enrico Marocco schrieb:

This turned into a very interesting discussion, too tempting to just
keep lurking :wink:

Even if verbal verification if probably the main characteristic of ZRTP,
it is not the only way for protecting from MiTM attacks. For example,
sections 7.2 and 8.1.1 in draft-*-zrtp-14 offer alternative mechanisms
which apply also to one-way channels. Or am I missing something?

For the way described in 7.2 you need some way to exchange Signatures.
Qualified Signatures usually require some Certificates, a Public Key
Infrastructure etc with all its problems regardig key and certificat
revocation, certificate updates, ... . This is the main reason why this
does not work for the normal users - even large companies struggle to
implement this :wink: .

To use the mechanisms described in 8.1.1 you need a full integrity protected
signaling path, for example integrity protected SIP End-to-End. RFC 4474 claims
this but in practice this RFC does guarantee end-to-end but sort of
"proxy-to-proxy" integrity where you need to trust your operator - or you need
a full certificate infrastructure again for each user. I've digged into this
some time ago, you may have a look at:

<http://www.fsfe.org/en/content/download/32472/201002/file/KeyExchangeDTLS-SRTP.pdf>

(this is a more broader analysis but covers RFC 4474 also)

The specific use of SAS and a simple way to compare it guarantees the security. No
need for other complex infrastructures or trust in somebody else - just you
and your communications partner.

Enrico

Regards,
Werner

<SNIP --- SNAP>

···

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


#9

Werner Dittmann wrote:

Just a bit more precise :slight_smile: See inside.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Hi Emil,

I'm quite reluctant to offer one-way communication for all
sessions.

I'm quite reluctant to offer one-way communication for all
ZRTP sessions.

Yes I believe that's what I understood. What I don't however is: does
this also mean that you'd prefer to deny users any encryption and thus
force them to communicate with clear media (or stop communicating) just
because we are not aware of a means they could use to verify SAS.

This is the only point that currently bothers me and the only reason why
I keep insisting :).

<SNIP --- SNAP>

An attack against ZRTP exists. Phil calls it the "Rich Little Attack":

Right. But the fact that the possibility of this attack exists does not
mean we should stop offering support for ZRTP. Besides we are not even
doing anything to warn our users against it inside the user interface
(and I am not saying we should). We are betting on the fact that it is
unlikely for such a thing to happen.

We have such a warning GUI in place. Currently it is implemented as
systray notification popup. If anything requires user attention then
we display a message and ask to user to take action.

My point was that we are starting a ZRTP session despite the possibility
of a "Rich Little Attack" and that we are not warning users that the SAS
verification process is not protecting them from it. And that's fine.
You have to draw a line somewhere and do your best which is far better
than nothing.

This is also why in the case of a one way stream we should be doing the
same: warn users that they are not completely protected before they
check the SAS but still do our best and start encrypting even if we are
not sure whether or not they'll be able to verify the SAS string.

Cheers
Emil

···

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


#10

Werner Dittmann wrote:

To use the mechanisms described in 8.1.1 you need a full integrity
protected signaling path, for example integrity protected SIP
End-to-End. RFC 4474 claims this but in practice this RFC does
guarantee end-to-end but sort of "proxy-to-proxy" integrity where you
need to trust your operator - or you need a full certificate
infrastructure again for each user.

Or anything among PGP, S/MIME, SIPSEC (draft-gurbani-sip-sipsec, whose
inclusion in the rfc3261bis-to-be has been extensively discussed and
quite agreed), or even XEP-0250. I agree that none of them looks as
widely deployable as the vocal comparison, but just ruling them out by
design seems too much of a limitation for a well-thought mechanism like
ZRTP.

···

--
Ciao,
Enrico


#11

Enrico,

the problem is "a full integrity protected signaling path".
This is very difficult, if not impossible to achieve.

The German government office responsible for making and breaking codes
does not permit PGP to be used for sensitive communications. They have
a reason for this.

Many companies are selling SSL & SSH-breaking firewalls, so this is not
a solution. SSL & SSH do not automagically offer security.

Do not forget that in all the security lists, discussion groups, and working groups
that there are
1- many naive people
2- always one or more participants representing a hidden agenda,
which is why weak security like WEP and GSM telephone network encryption
happen.

ZRTP with verbal SAS is the easiest and most secure procedure for today.
There are more than enough unused, and therefore wasted, pixels to inform
Joe the plumber about correctly using SAS.

> just ruling them out by design ............
the GSM encryption was ruled in by design. Therefore, the only conclusions:
do not trust security lists
do not trust discussion groups
do not trust working groups
do not trust XMPP specs

regards, Earl

Enrico Marocco wrote:

···

Werner Dittmann wrote:
  

To use the mechanisms described in 8.1.1 you need a full integrity
protected signaling path, for example integrity protected SIP
End-to-End. RFC 4474 claims this but in practice this RFC does
guarantee end-to-end but sort of "proxy-to-proxy" integrity where you
need to trust your operator - or you need a full certificate
infrastructure again for each user.
    
Or anything among PGP, S/MIME, SIPSEC (draft-gurbani-sip-sipsec, whose
inclusion in the rfc3261bis-to-be has been extensively discussed and
quite agreed), or even XEP-0250. I agree that none of them looks as
widely deployable as the vocal comparison, but just ruling them out by
design seems too much of a limitation for a well-thought mechanism like
ZRTP.

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