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.
-Ekr
