On Thu, Mar 5, 2009 at 1:24 PM, Dirk Meyer <[email protected]> wrote: > 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.
I think it's pretty important to recognize that there is a qualitative difference between SCRAM and SRP that isn't just a matter of what layer it's at. SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. Obviously, you could do something SRP-oid at the app layer, but we really should decide if dictionary attack resistance is an important element. -Ekr
