Re: [TLS] Straw poll on TLS SRP status

[Tom Wu <tjw at CS.Stanford.EDU>]

Martin Rex:

> The document status is pretty much the only "incentive" that the
> IETF can put out for companies to slow down on their patents race
> or at least to come up with reasonable licensing terms (i.e. royalty free
> for Free and OpenSource software).

Keep in mind that in the context of this discussion, Stanford (SRP) and
Lucent (EKE) are competitors.  Knocking down TLS-SRP from Proposed to
Informational/Experimental rewards the player that did not do the "right"
thing (free licensing) at the expense of the player that did the "right"
thing (Stanford).  The last thing you want to do is to create an incentive
for players to do an IPR "denial of service" on a competitor's technology,
since this encourages "patent race" behavior.

Yoav Nir:

> I think SRP should not be a stand-alone extension, but rather that it should be introduced as part of EAP.

At the risk of being a bit blunt, if the EAP approach is so great, why has
more support grown around TLS-SRP instead?  I would also add that the two
parts of your statement are not mutually exclusive.  If you want to advance
EAP-SRP in TLS, great, but it is not a valid reason to slow down a standard
that is already in use and has seen a lot of scrutiny.

> I know SRP has the capability to do the whole key exchange, but why do we need it.

Perhaps we want the session to be secure against MITM attacks?

> The problem that both extensions are trying to solve is the problem of using passwords for authentication within TLS.
> TLS has a perfectly good way for keying already.

This is not necessarily directed at you in particular, since I've seen
several comments of this flavor in this discussion - there's this
assumption that transport security and password authentication are
separable and modular, but in the context of strong password protocols,
this assumption is false - in fact it is precisely this kind of
separation that would allow a MITM attack.  Password authentication
with low-entropy passwords is Harder Than You Think.  Little things
like which party sends which message first or whether one message
should only be sent after some other message has been received,
those can spell the difference between a secure password protocol
and an insecure one.  The TLS-SRP standard represents a great deal
of tweaking and analysis to make sure all the details are right.

Without a specific alternative password protocol to subject to
scrutiny, EAP or any other general proposal cannot really be
presented legitimately as an altenate "choice" to TLS-SRP at
this time since there is no way evaluate its security.  Just
saying it's SRP isn't enough without knowing how the transport
encryption/MAC keys are tied to the password-based key exchange.

Tom
--
Tom Wu
http://www-cs-students.stanford.edu/~tjw/

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls