Subject: [TLS] Moving forward on draft-ietf-tls-srp

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Nov 2005 10:26:37 -0800

Folks,

draft-ietf-tls-srp has been hanging around the WG for quite some time
and I'd like to get a sense of the WG on advancement. The general
sense of the WG at YVR was that we should be working to move it
forward somehow, but it wasn't clear how. The big question for
me is whether it should be Informational or Proposed. The issue,
of course, is the uncertain IPR situation.

So, I'd like to get comments on:
1. Should this document advance?
2. Should we be advancing it as Proposed or Informational?

As a secondary considertion, I note that the current version has
the unattractive property that the client has to take extreme
care about what groups it accepts because a properly chosen server group
may allow a fake server to extract information about the 
user's password. I'm not familiar enough with the PAKE literature
to know if this is an essential feature of PAKE protocols. If
not, should we be considering a different base cryptographic
protocol?

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Thomas Wu <[email-masked]>
Date: Mon, 28 Nov 2005 11:28:40 -0800 (PST)

> 1. Should this document advance?

Yes

> 2. Should we be advancing it as Proposed or Informational?

I support advancing it as Proposed, given that its multiple
interoperating implementations meet the criteria for "Licensing
Requirements to Advance Standards Track IETF Documents" as
described in RFC 3979, Section 10.

> to know if this is an essential feature of PAKE protocols. If

The client must avoid "trapdoor" groups that allow easier-than-normal
computation of discrete log via SNFS instead of GNFS.  This applies
to any password protocol whose security is based on the difficulty
of the discrete log problem, so it would not just be SRP, but DH-EKE,
SPEKE, AMP, etc.  The vast majority of SRP implementations check the
received parameters against the groups listed in Appendix A, which
seems to work quite well in practice.

> -Ekr

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

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 29 Nov 2005 10:32:38 -0800

Thomas Wu wrote:
> I support advancing it as Proposed

+1, of course, from another of the authors.

For those not at Vancouver, the TLS/SRP slides might be a useful refresher:

http://trevp.net/tls_srp/ietf_tlssrp.ppt

At the IETF meeting, the authors also invited technical review and 
comments, and I'll repeat that invitation here.  The draft is 
essentially done (from our point of view), so now would be a great time 
for people to read it and send us feedback.

One comment we've already noted is that the draft should use TBD-IANA 
for its numbers.

Trevor

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 29 Nov 2005 20:09:56 +0100

> +1, of course, from another of the authors.

+1 from another authors' site.
> http://trevp.net/tls_srp/ietf_tlssrp.ppt
As already mentioned by Tom, client site validation of the group 
parameters can be easily done
by comparing it to a fixed list in the client.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Nov 2005 11:34:31 -0800

> by comparing it to a fixed list in the client.

That's not really validation: it's effectively a fixed set of system
parameters--which isn't something, for instance, that the current
DH cipher suites have.

-Ekr