[GnomeMeeting-list] Re: GnomeMeeting and encryption

[Damien Sandras <dsandras seconix com>]

Hi,

> > It is sent unencrypted. However, you can setup a VPN at the kernel-level
> > to allow encryption if you require it.
> 
> This is not really a useful solution, any more than a VPN is an alternative 

That's the more efficient.

> to PGP for email.  Unless I know what machine the other person is at and we 
> both have root access and there are no problematic NATs or firewalls and no 
> relays are required and I successfully VPN all the connections needed - 
> RTP, RTCP, SIP, some random collection of H.323 kinds of traffic - that's 
> not going to help.  And I doubt anyone has ever successfully done this. 

I have ;)

> Far easier to use the ancient creaking speakfreely with its own protocol. 
> Not that that is easy!
> 
> There's no reason this should be any harder on the user than SSH (or even 
> PGP).  Of course, it seems that the standardized protocols bury their 
> encryuption specs under a morass of documents.
> 

Indeed. I agree encryption is important stuff. But there are also other
important things to implement. People want SIP, people want a Windows
version, and that is what they will get before encryption support. Of
course, if somebody has time to work on a patch, it will be incorporated
in the source code. However, requests are more frequent than code
contributions.

> >>authrntication?  That is, do I have any assurance that the person I think 
> >>I'm talking to is actually at the other end?
> > 
> > If you are using a gatekeeper with authentication, then you will be sure
> > to talk to the right person thanks to H.235 authentication.
> 
> What does this actually mean?  Who is authenticating what fact and on whose 
> authority?
> 
> What I mean is: If I get a PGP mail from someone and the signature is okay, 
> I can trust that it is unmodified as sent by the owner of the secret key 
> that made the signature.  If I have a web of trust connection to the owner, 
> then I can be pretty confident that it's really who I think it is; if not, 
> at least I can be confident that no new problems have arisen after the 
> first connection (since I keep the public key and don't allow substitutions 
> after the first message).
> 
> What does a "gatekeepr with authentication" certify?
> 

The H.235 standard addresses four general issues when dealing with
security, Authentication, Integrity, Privacy, and non-Repudiation.
Authentication is a mechanism to make sure that the endpoints
participating in the conference are really who they say they are.
Integrity provides a means to validate that the data within a packet is
indeed an unchanged representation of the data. Privacy/Confidentiality
is provided by encryption and decryption mechanisms that hide the data
from eavesdroppers so that if it is intercepted, it cannot be viewed.
Non-Repudiation is a means of protection against someone denying that
they participated in a conference when you know they were there. Hooks
for each of these security features are specified in H.323 Version 2.
The proper usage of these hooks is specified in H.235. This content
comes from the Packetizer Web site. For more on Packetizer, see:
http://www.packetizer.com/iptel/h323

Encryption/decryption are not supported by GM yet.

> > However, in general, his voice or his video stream will allow you to
> > determine it too.
> 
> Well, it determines that someone who sounds like that was involved in the 
> connection somehow, although for all I know I might be seeing footage 
> recorded long ago and pieced together, or it might be being relayed through 
>   somebody who can substitute in archival footage when appropriate 
> (changing a "yes" for a "no", accompanied by a dropped frame or two of 
> video, say).

;-))

> 
> I'm not really trying to be difficult, but there's really no reason this 
> shouldbe much harder than SSH or PGP for the software authors either - I 
> actually wrote a working VoIP application with that kind of security a 
> couple years ago.  Not standards-based and not with a decent UI, so not 
> really useful, but it shows the problem is solvable.  If it weren't for the 
> standards.
> 

The probably you could help and work on a patch. If not, you will have
to be patient. 
I think encryption for SIP could come before encryption for H.323.
-- 
 _      Damien Sandras
(o-     GnomeMeeting: http://www.gnomemeeting.org/
//\     FOSDEM 2005 : http://www.fosdem.org
v_/_    H.323 phone : callto:ils.seconix.com/dsandras seconix com