Re: [TLS] draft on new TLS key exchange

["Dan Harkins" <[e-mail]>]

On Wed, October 5, 2011 5:39 pm, Jean-Marc Desperrier wrote:
> On 06/10/2011 01:07, Dan Harkins wrote:
>> TLS is rife with drafts and RFCs that have the same aim but go about
>> it differently
> Even if there might indeed be quite a few like that in the TLS case,
> it's still against IETF policy.

  I asked Peter and I'll ask you: why have you not brought up this
with Camellia, SEED, and Clefia?

  And I'd be really interested in seeing the IETF policy statement
that mandates one and only one way of doing one particular thing.

> There should be at least some specific advantage to your approach over
> the other one (or enough existing usage to justify documenting it
> through an experimental RFC), which is far from being proved for now.

  I don't think such language is appropriate for an I-D. But in an
email exchange I'll tell you that this scheme allows the cryptographic
strength of the domain parameter set to be matched with ciphersuites of
commensurate strength. This also allows for the use of elliptic curves.
It doesn't hard-code a particular hash algorithm (that the IETF is
planning on moving away from) so it's more "crypto agile".

> SRP has the advantage over the other PAKE to be covered by a defensive
> patent with a royalty free license, which makes it safer to use.

  This key exchange is not patented.

> If needed, it's also actually very easy to use SRP in symmetric mode,
> regenerating the verifier from the password on the fly.
> Nothing in RFC5054 says how the client sends the verifier to the server
> initially. If you really want to send the password instead, you just can.

  You can change the way RFC 5054 works but then it's not SRP anymore and
then people will start telling you that it's "against IETF policy".

  Furthermore, the client doesn't send the verifier to the server in SRP
so I'm not really sure what you're talking about.

  Dan.