Eric Rescorla wrote: > On Thu, Mar 5, 2009 at 7:43 AM, Justin Karneges <[email protected]> wrote: >> This is exactly why I think we should try to find a solution that doesn't >> require modification to existing TLS APIs. We've already felt enough pain >> just from XML APIs being inadequate for XMPP streaming (are people done yet >> homebrewing their parsers with Java/.NET?). Let's not repeat all of that >> again with TLS, at least for the common scenarios we are targetting. > > This is of course reasonable, but if the solution involves writing a > whole bunch of new crypto code in XMPP that seems undesirable as well, > no?
I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and it only lacks support in some bindings. Instead of writing something outside TLS just for us, writing a patch to the bindings could take the same coding time. Except doing that provides something usefull outside the XMPP community. The same is true for channel bindings: the libs support it and you only need to add SCRAM support + get the Finished messages into the used SASL lib. As for DotNet, J2ME, and friends it is different. They lack SRP support in the core and you can not just patch the lib. On the other hand GnuTLS runs on Windows and is LGPL, so it can be used inside a closed-source application. Creating C# bindings shouldn't be harder than for any other language. Dirk -- If you can't beat your computer at chess, try kickboxing.
