But more importantly, nobody uses TLS-SRP. No browser implements it. The demand for PAKE authentication in TLS is not strong. I'd argue that there's no demand

But more importantly, nobody uses TLS-SRP. No browser implements it. The demand for PAKE authentication in TLS is not strong. I'd argue that there's no demand for TLS-SRP because most of the people who could make use of it don't even know it exists. (Conventional thinking is that the only way to do authentication in TLS is with X.509. TLS-PSK has the same problem.) But applications can't reasonably support TLS things that the TLS libraries they use don't support. Two of the three elephants in the TLS room, SChannel and NSS, don't support TLS-SRP. The other elephant, OpenSSL, has supported it for less than two years. There's interest in (and patches for) adding TLS-SRP support to NSS, but they don't seem to want to implement anything that Firefox won't use: https://bugzilla.mozilla.org/show_bug.cgi?id=356855#c25 https://bugzilla.mozilla.org/show_bug.cgi?id=356855#c25 (As an aside, I think NSS's position on supporting TLS-SRP highlights the biggest problem with chaining your code to a library produced by another entity for their own use: unless you have the ability to fork and maintain it yourself, your future use of that library is at the mercy of the other entity's interests. Fedora is porting all of their TLS-using packages to Mozilla's NSS, a project that exists for other Mozilla products' benefit. node.js is joined at the head to Google's V8, a JavaScript engine that exists for Chrome's benefit. My crystal ball shows both situations ending very badly when these projects' needs and directions get far enough out of alignment.)