On 06/03/2009, at 2:33 PM, Eric Rescorla wrote:
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
re: "if dictionary attack resistance is an important element."
It is 'defense in depth.'
David.
--------------------------------------------------------------------------------------------------------
Email Filtering by Cleartext a Carbon Minimised company - www.cleartext.com
--------------------------------------------------------------------------------------------------------
