On 3/5/09 8:43 AM, Justin Karneges wrote: > On Thursday 05 March 2009 05:48:22 Dirk Meyer wrote: >> Simon Josefsson wrote: >>> Having more feedback on what kind of features XMPP wants from TLS >>> libraries will help TLS implementers (at least it will help me), and >>> making the requirements explicit may help the decision on what is the >>> best choice for XMPP too. >> For OpenSSL and GnuTLS it is more about features of the bindings. Both >> libs have SRP and Finished message support for channel-bindings. But the >> Python bindings (that is what I care about) only support X.509. Well, it >> is even worse: OpenSSL's Python bindings are old and not updated >> anymore, GnuTLS does not have real bindings (only some strange ctypes >> based code flying around without real project homepage). >> >> I don't know about Ruby, C#, or any other language. GnuTLS only seems to >> have suitable Guile bindings -- but seriously, who uses these? > > 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.
By that reasoning it was stupid for Jeremie to use XML for the original Jabber technologies when he started to design them in 1998 (XML was very new at the time, library support was missing on many platforms, etc.). So let's say we decide that we want to use Secure Remote Password (SRP) in TLS because it has the best combination of security and usability (I'm not making that claim yet, just positing it for the sake of argument). The SRP support in OpenSSL and GnuTLS is quite recent (not yet in all language bindings), support does not yet exist in .NET and some other platforms, etc. If we really think that TLS-SRP is compelling then the solution is to cajole TLS developers, submit patches, whatever we need to do. The same thing goes for channel bindings if we decide to go that route. The "common scenarios we are targetting" for e2e are perhaps not so common because most people think of TLS as being used between a client and a server (a web browser connecting to a web server, an IM client connecting to an IM server), not between two human-controlled peers that need to perform mutual authentication (probably of end-user certs). So it's not clear to me that our scenario is common at all! The "common" case for c2s or s2s with mutual authentication involves X.509 certs. If IM clients generate self-signed certs as we've discussed, then we need a way to do mutual authentication (unless we propose that people take a leap of faith a la SSH). That's not so straightforward, and from our discussion so far seems to require either SRP or channel bindings, or potentially something homegrown (which puts us outside the security mainstream). We could propose the use of CA-issued certs (and we have a CA that could do so), but that has its own set of usability issues, the need for CRLs or OCSP (for which support is also not widespread), etc. The basic problem here is that we're at the cutting edge, and when you do that you're bound to get sliced up a bit. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
