I am not a fan of TLS as it has the inherent issue of being hop-by-hop. Unless you can verify the entire signaling path is secure then it is useless. Certainly you can verify from you endpoint to the gatekeeper is secure but what about beyond that. Certainly for small closed deployments it can be useful but for large adhoc network it can be problematic.

I have a contribution to the next meeting proposing that the ITU discuss the security issues with regards to H.235.6 and MiTM attackes and propose the group makes a decision on whether there is merit in developing a new H.235 standard. The really good thing with H.235 it supports end to end which there is no equivalent in SIP.

Many years ago I developed an idea which I called eaRTP encryption and authentication with RTP. The idea was to use PKI and the keys where provisioned by the gatekeeper when registering. Most likely via a URI fields in the RCF . The actual key generation is done separately when the account is created.

When a call is placed the certificate is signed embedded and the first half of the Diffie Hellman is sent in the clear. The remote authenticates the certificate and encrypts the reply Diffie Hellman with the certificate supplied from the remote so only the caller can decrypt it. It would also sign it's own certificate. This way each party is authenticated and only half of the Diffie Hellman is exposed. If DH key sizes of 2048 bits or greater are used (rather than the current 1024) it makes it very difficult to derive the key to unlock the media streams. Moving to AES256 (rather than current AES128) would assist greatly. BTW each media stream has its own unique key so as long as that diffie hellman is large and is protected it makes it very difficult to crack those keys. The other advantage is that there is some backwards compatiblity and would work across any existing H.323 network. TLS is not implemented other than with GnuGk.

I hope to have to have a lively discussion on the topic in Geneva next month.

Simon

-----Original Message----- From: h323implementers-bounces@lists.packetizer.com [mailto:h323implementers-bounces@lists.packetizer.com] On Behalf Of Jan Willamowius Sent: 23 September 2013 23:39 To: openh323gk-users@lists.sourceforge.net Cc: h323implementers@lists.packetizer.com Subject: Re: [h323implementers] [Openh323gk-users] [Openh323gk-developer] Thoughts on H.323 encryption or Why your AES encryption might be worth nothing

Simon Perreault wrote:

Le 2013-09-23 15:09, Jan Willamowius a écrit :

...

GnuGk currently checks the certificates signature (either against your own CA or the public CAs you configure) and can also check if the IP the call comes from matches the certificate.

The weak point here is, and has always been, the necessary PKI infrastructure. Way too complex to set up and maintain.

A way to untie this knot could be to use DANE, a protocol for verifying TLS certificates using self-published DNSSEC records. No need

for a CA.

There is this proposal for SIP, but one could easily imagine an H.323 equivalent:

https://tools.ietf.org/html/draft-johansson-dane-sip-00

I'd be happy to support DANE in GnuGk, but the current lack of PKI infrastructure should not serve as an excuse not to implement TLS at all.

There are a lot of H.323 installations with a rather closed user group that can happily live with their own private CA, except you can't get any endpoints doing TLS at all...

Regards, Jan

-- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan@willamowius.de Website: http://www.gnugk.org Support: http://www.willamowius.com/gnugk-support.html

Relaxed Communications GmbH Frahmredder 91 22393 Hamburg Geschäftsführer: Jan Willamowius HRB 125261 (Amtsgericht Hamburg) USt-IdNr: DE286003584