Eric Rescorla <[email protected]> writes: > On Fri, Mar 6, 2009 at 1:34 AM, Simon Josefsson <[email protected]> wrote: >> Eric Rescorla <[email protected]> writes: >> >>>> 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. >> >> There is a SRP SASL mechanism: >> >> http://www.watersprings.org/pub/id/draft-burdis-cat-srp-sasl-08.txt >> >> I believe it has been implemented, but not widely deployed. > > Right. Both symmetric and PAKE-based systems can be implemented > both at the TLS layer (PSK and SRP), and at the application layer > (SASL-{Digest,SCRAM,...} and SASL-SRP). So, this isn't really an > argument about which layer things should be done at. I just think > it's important to be clear about what various components are bringing > to the party.
Perhaps what is missing here is a ... threat model. Do we have a list of attacks that XMPP wishes to protect against by using TLS/SASL/etc? I may have missed it, but I think it would help to find a solution if we first agree on what problems there are. /Simon
