Subject: [ietf-tls] Server authentication when using SRP, and cipher suite numbers

From: David Taylor <[email-masked]>
Date: Mon, 12 Mar 2001 20:57:55 +1100

I have been thinking about the lack of server authentication when using the SRP authentication, and received a question from someone else regarding the problem too.

I have not thought of a way to achieve this without using a server certificate, which brings certificates back into the protocol, which I was trying to avoid.

Of the people who have put TLS into an installed application, has validating the server certificate been a problem? Or was it just ignored?

Also, what is the convention for getting cipher suite numbers from IANA? Should I do that now with the internet draft, or wait and see if it lasts past the first revision?

Regards,
David Taylor
Forge Research Pty Ltd.

http://www.forge.com.au
http://www.protekt.com

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 03:11:46 -0800

David Taylor <[email-masked]> writes:
> I have been thinking about the lack of server authentication when
> using the SRP authentication, and received a question from someone
> else regarding the problem too.
I'm a little confused as to what you're saying here: part of the point
of SRP is to mutually authenticate the client and server using a
password. I.e., the password is what authenticates the server.

>  I have not thought of a way to achieve this without using a server
> certificate, which brings certificates back into the protocol, which
> I was trying to avoid.
What would you consider "authenticating the server" if the password
isn't enough? 

>  Of the people who have put TLS into an installed application, has
> validating the server certificate been a problem? Or was it just
> ignored?
No, in real applications the server certificate (if there is one)
should be validated.

>  Also, what is the convention for getting cipher suite numbers from
> IANA? Should I do that now with the internet draft, or wait and see
> if it lasts past the first revision?
IANA does not distribute cipher suite numbers. The convention has
been to simply invent some (using the next unused [even in drafts] 
number).

That said, a couple comments:
(1) There's no reason to have such an unwieldy exchange of messages.
The SRP authentication messages can be wedged into the standard
handshake structure (with an extension to carry U)

ClientHello: U (in an extension)
ServerKeyExchange: g, N, s, B
ClientKeyExchange: A

The server does not need to know A to generate B.

(2) Your placement of U in the ClientHello will conflict with
draft-ietf-wireless-00.txt. You should phrase this as an extension
so that implementations will be able implement both drafts.

(3) If you want to allow for server authentication via certificate,
the easiest way to solve your above authentication problem is simply
to allow for signature of the server on the ServerKeyExchange (which
of course is already in the protocol).  You could even have the SRP
extension to indicate this:

Something like:

enum {
    none(0), rsa_sign(1), dss_sign(2), (255)
} ServerCertificateType;

struct {
   ServerCertificateType certificate_types<1..2^8-1>;
   DistinguishedName certificate_authorities<3..2^16-1>;
} ServerCertificateRequest;

struct SRPInfo {
	opaque user_name<2^8-1>;
	ServerCertificateRequest certificate_request;
}

The above structure could probably be made more elegant with a
little work.

-Ekr

---

---

From: Ben Laurie <[email-masked]>
Date: Mon, 12 Mar 2001 11:58:36 +0000

> Of the people who have put TLS into an installed application, has validating the server certificate been a problem? Or was it just ignored?

What do you mean by "validating the server certificate" - checking
against a CA? Checking the hostname? Both? Something else?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/

---

---

From: Dj Browne <[email-masked]>
Date: Mon, 12 Mar 2001 08:28:43 -0500

Hi,

I cannot speak for David of course, but there may be a situation where the 
server may need to be validated outside of SRP (using PKI).  I might be 
wrong but if some one has stolen the passwd from the client then they can 
perform mutual authentication with the server....they could even act as a 
server for that particular client. No?

If the server also carried a signed cert then stolen passwds from the 
client would not allow server spoofing.

Just a thought...please correct me if I am wrong

Later,
dj

At 3/12/2001 11:58 AM +0000, Ben Laurie wrote:
>David Taylor wrote:
> >
> > I have been thinking about the lack of server authentication when using 
> the SRP authentication, and received a question from someone else 
> regarding the problem too.
> >
> certificate, which brings certificates back into the protocol, which I 
> was trying to avoid.
> >
> validating the server certificate been a problem? Or was it just ignored?
>
>You are currently subscribed to ietf-tls as: [email-masked]
>To unsubscribe send a blank email to 
>[email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 08:54:10 -0800

> server for that particular client. No?
Yes, that's correct. 

> client would not allow server spoofing.
If you're going to do this then why use SRP at all?  Just use
passwords over the SSL connection directly.

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 12 Mar 2001 12:02:56 EST

> passwords over the SSL connection directly.

You don't want to send passwords to a host.  Even if the connection is
secure because the host might have been root hacked. 

SRP significantly increases the cost associated with stealing passwords 
even if the hash file has been stolen.

However, if you want the combination of X.509 certs and then SRP,
simply negotiate TLS with an RSA or DSS cert and then perform an SRP
exchange at the application level.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 09:12:29 -0800

> even if the hash file has been stolen.
I don't buy this. The point of the exercise, recall, is to protect
access, not passwords. If someone has compromised the host's private
key, you're in a world of hurt. Protecting your password at this stage
in the game seems like a pretty minimal value-add.

-Ekr

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 12 Mar 2001 12:15:47 EST

> in the game seems like a pretty minimal value-add.

Except that people tend to use passwords for more than one system.
The host and the users are typically not under the same domain of

control.  It is not always possible to convince users to change their
passwords (or private keys).  Therefore, to whatever extent possible
they should be protected.

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 09:30:15 -0800

> they should be protected.
Sure, but adding SRP purely to protect against this attack seems
to me be massive overkill and does nothing to prevent a whole
suite of easy to mount attacks. Here's one:

The banner message on the system (which you've logged into encrypted,
recall) says:

	"Your password has expired. Please change your password
	 immediately".

Now, even fairly savvy people will (rightly) consider this to be
safe. Since Unix password changes require you to input your old
password first....  Shazam, the attacker's got your password.

People are stupid. Technical countermeasures will only go so far
to protect them from themselves.

-Ekr

---

---

From: Tom Wu <[email-masked]>
Date: Mon, 12 Mar 2001 10:10:27 -0800

> password. I.e., the password is what authenticates the server.

I agree - the server is authenticated, but not explicitly via posession
of a server cert + key, but implicitly, via possession of the user's
verifier.  As is the case with Kerberos V5, I think server certs are
outside the scope of the authentication mechanism.

> The server does not need to know A to generate B.

I wish the exchange could be simplified as such.  But the server can't
send B before getting A because it leads to an attack (it's described in
my paper, section 3.2.4).

> extension to indicate this:

I'm not sure what explicit server authentication buys anyone, since
someone who roots the server can steal a private key just as easily as a
password database.  I know someone's going to bring up HSMs, but I'd
suggest encrypting the password database with a key that is kept in the
HSM.
-- 
Tom Wu
Principal Software Engineer
Arcot Systems
(408) 969-6124
"The Borg?  Sounds Swedish..."

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 10:24:00 -0800

> > ServerKeyExchange: g, N, s, B
n> > 
> my paper, section 3.2.4).
My bad. I missed this line in RFC 2945.

Note that if TLS were to commit to a single DH group for SRP
then it appears that A could be sent with U, since the salt
is only used at a later stage.

> suggest encrypting the password database with a key that is kept in the
I agree with you on this, though perhaps for different reasons.

-Ekr

---

---

From: David Hopwood <[email-masked]>
Date: Tue, 13 Mar 2001 05:46:02 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> passwords over the SSL connection directly.

Doing that is less secure than SRP with certificates, because it tells
the server the client's password directly. That means that security is
dependent on the user checking the server's certificate, and on users
not using the same password (or related passwords) for more than one server.
Neither of those are good assumptions to make.

I agree completely with Eric Rescorla's suggestion of optionally signing the
ServerKeyExchange (which is more efficient than negotiating SRP on top of
another ciphersuite, and IMHO simpler).

Eric wrote:
> Here's [an attack where a compromised server can find the user's
> cleartext password]:
>

That is why the password should be changed by having the client's software
specify a new verifier and salt, rather than giving the new password itself
over the connection.

This also has the advantage that it makes it trivial to support two-factor
authentication: the client gives a dummy salt, and stores the actual salt
on a smartcard. Now neither obtaining the server's password file nor
stealing the smartcard is sufficient to log in; the password is also needed
(and in the case where the smartcard was stolen, the password is still not
subject to off-line dictionary attack).

Ideally, changing the password would be part of the SRP-over-TLS protocol,
so that it can be implemented by the TLS library, and so that a user can
change his or her password at any time during a connection. This would also
simplify using password authentication with existing applications and
protocols.

Tom Wu wrote:
> I'm not sure what explicit server authentication [via certificates] buys
> anyone, since someone who roots the server can steal a private key just
> as easily as a password database.  I know someone's going to bring up
> HSMs, but I'd suggest encrypting the password database with a key that
> is kept in the HSM.

That involves having the password in the server's memory at some point.
Using SRP with server certs, and doing the key exchange completely within
the hardware module, is much more secure in terms of allowing recovery from
compromise.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: Eric Rescorla <[email-masked]>
Date: 12 Mar 2001 22:40:39 -0800

David Hopwood <[email-masked]> writes:
> the server the client's password directly.
Yes, it's less secure, but it's simpler, faster, and doesn't require
any changes to anything. There's a lot to be said for that. The
question is whether the increase in security is worth the additional
hassle.

> specify a new verifier and salt, rather than giving the new password itself
While this will work technically I don't believe that it will work
operationally.  Recall that the problem here is stupid users who can
be tricked into providing passwords over what is, after all, an
encrypted connection. How are we going to teach people stupid enough
to click "ok" when the "this certificate is signed by an unknown CA"
dialog comes up not to type their passwords over encrypted channels.

Moreover, if the user also potentially logs into the machine locally
then you need to change the ordinary password system as well. On Unix this
requires replacing 'passwd', which isn't _that_ bad on non-networked
systems but is pretty bad on NIS-based systems because it also
requires changing rpc.yppasswd. There's not a lot of market for solutions
which require displacing your entire security infrastructure.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

---

From: David Taylor <[email-masked]>
Date: Tue, 13 Mar 2001 22:47:09 +1100

> password. I.e., the password is what authenticates the server.

As others have pointed out, it is easy to pretend you are the server
when you have the password verifier file.

>No, in real applications the server certificate (if there is one)

I know they *should* be validated; I was asking if they *are* validated...

My reading of the way things are at present (which is purely a hunch)
it that most people create their own certificates because they need them
or TLS won't work, not because they use them for authentication. I think
most people ignore the server certificate and just use a name and password
after the channel is encrypted. I am happy to be shown to be wrong here.

From the Java perspective, the JSSE trust handlers were awfully complex
last time I looked, and I thought storing trusted certificates in a keystore
would be okay, until I tried it in practice with real customers. Then I changed
my mind.

I don't particularly want to use server certificates for server authentication but
I cannot think of a better way. I take the point regarding it is just as easy to
steal a private key file as it is a password verifier file. I had this conversation in
the office recently regarding using SRP for another project, and we decided the
most secure way to handle it was to have the SRP algorithms and verifier file on
a smart card, with the verifier file in write only (from the outside). Same for the
server certificate I think, as at least then the attacker must steal the smart card.

Anyway, there are a number of questions I should have posted:

1. Does server authentication matter in this case (this case being a simple way to
combine client authentication with TLS, and doing away to X.509 certificates from
the TLS handshake)?

2. If server authentication matters, is server X.509 certificates the way to do it?
At first glance it looks easy enough to add them to the handshake.

3. If server authentication matters, and X.509 isn't good enough because we still
don't have a real PKI, what is another alternative?

Thanks to all for the ideas and input.

Regards,
David Taylor
Forge Research Pty. Ltd.

---

From: Eric Rescorla <[email-masked]>
Date: 13 Mar 2001 09:01:55 -0800

> after the channel is encrypted. I am happy to be shown to be wrong here.
I don't know what "most people". Noone with any brains does what you
suggest because doing so is completely worthless against active attack.
The most popular SSL implementations (Netscape and IE) both check
certificates.

BTW, you DON'T need certificates to get TLS to work. TLS has 
anonymous DH. You need certificates to get the abovementioned
implementations to work, however, because they check certificates.

> >From the Java perspective, the JSSE trust handlers were awfully
> complex last time I looked, and I thought storing trusted
> certificates in a keystore would be okay, until I tried it in
> practice with real customers. Then I changed my mind.
Last time I looked at JSSE it was ridiculously overcomplicated
so I wouldn't use that as a guide. It's possible to do this job
relatively simply if you restrict yourself to the common cases.

If you have a relatively fixed set of CAs you can simply compile the CA
key(s) into the application.

>I don't particularly want to use server certificates for server
>authentication but I cannot think of a better way. I take the point
>regarding it is just as easy to steal a private key file as it is a
>password verifier file. I had this conversation in the office recently
>regarding using SRP for another project, and we decided the most
>secure way to handle it was to have the SRP algorithms and verifier
>file on a smart card, with the verifier file in write only (from the
>outside). Same for the server certificate I think, as at least then
>the attacker must steal the smart card.
The problem here is that you can get hardware that will implement
your private key algorithms but you cannot currently get hardware
to implement SRP.

The bottom line is that if you have trusted hardware support for your
private key operations then there's some value-add for certificates
+ SRP. If you don't have hardware then there isn't any. Thus, if
you're really paranoid it would pay to use both and I guess if you
believe that there are a lot of people who are really paranoid
it's worth putting it in the standard, since it's so easy.

> 1. Does server authentication matter in this case (this case being a
> simple way to combine client authentication with TLS, and doing away
> to X.509 certificates from the TLS handshake)?
It's a matter of belt and suspenders. If you're worried about
theft of the keyfile then certificates will help.

> 2. If server authentication matters, is server X.509 certificates
> the way to do it?  At first glance it looks easy enough to add them
> to the handshake.
That's how I'd do it.

> 3. If server authentication matters, and X.509 isn't good enough
> because we still don't have a real PKI, what is another alternative?
I don't think so. X.509 can be used (clumsily) to ape all the
other certificate constructs (SPKI, PGP) and your implementation
is far more likely to have an X.509 processor.

-Ekr

[Eric Rescorla                                   [email-masked]]
Author of "SSL and TLS: Designing and Building Secure Systems"
                  http://www.rtfm.com/

---

---

From: Tom Wu <[email-masked]>
Date: Tue, 13 Mar 2001 11:23:35 -0800

David Taylor wrote:
> authentication but
> simple way to

It seems like regular X.509 server certs are the best way to do explicit
server authentication for those who want it and are willing to go
through the trouble (and expense) of getting one, since there's already
an infrastructure for dealing with it.

> At first glance it looks easy enough to add them to the handshake.

I would suggest the following arrangment for integrating a server cert
into the protocol, based on the diagram in the SRP-TLS I-D, and using
(*) to indicate optional components:

          Client                                 Server
            |                                      |
       Client Hello (U) ------------------------>  |
            |  <---------------------------- Server Hello
            |  <---------------------------- Certificate*
            |  <---------------------------- Server Key Exchange (g, N,
s)
            |  <---------------------------- Server Hello Done
       Client Key Exchange (A) ----------------->  |
            |  <---------------------------- Server Key Exchange (B)
            |  <---------------------------- Server CertificateVerify*
       change cipher spec                          |
       Finished -------------------------------->  |
            |                                change cipher spec
            |  <---------------------------- Finished
            |                                      |

The "Server CertificateVerify" message will be a signature computed on a
digest of the handshake messages (like the client CertificateVerify)
using the server's private key.  The digest will include (and thereby
authenticate) g, N, s, and B.  Comments?

---

---

From: "David A Taylor" <[email-masked]>
Date: Wed, 14 Mar 2001 09:30:53 +1100

>The most popular SSL implementations (Netscape and IE) both check

That's true. I'm not coming from the HTTPS perspective though. I'm thinking
about the RFCs and I-Ds that talk about adding TLS to IMAP, SMTP, FTP etc.
Clients and servers of these protocols may not use the Netscape or
Microsoft TLS implementations, and may not have the default set of trusted
signer certificates available. Plus, the servers may not use a
Verisign/Thawte/whatever signed certificate, instead using a self-signed
one. Again, a guess.

One thing that prompted me was remembering a comment regarding leaving
anonymous cipher suites in the TLS spec for implementations such as these,
and then using a name/password later. My idea was to get the name/password
into the handshake so you didn't have to do it later, while not losing
anything from an anonymous TLS setup.

>anonymous DH.

True.

>relatively simply if you restrict yourself to the common cases.

Also true. We didn't implement JSSE trust handling for that reason. I
thought using a keystore would be a good tradeoff between usability and
flexibility, but it turns out to be a hassle for users too.

>key(s) into the application.

Until the trusted signer certificates expire, or are compromised and
changed etc.

>> the way to do it?  At first glance it looks easy enough to add them

Other people agree. If a way to do this emerges that the list thinks is
good, I'll add it to the I-D.

>is far more likely to have an X.509 processor.

I was hoping to get away from certificates altogether for this 3rd
question, not just use an alternate certificate scheme.

-Ekr

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

Regards,
David Taylor.

Forge Research Pty Ltd
Suite 116, Bay 9, Locomotive Workshop
Australian Technology Park, Cornwallis Street
Eveleigh NSW 1430 Australia
Phone: +61 2 9209 4152   Fax: +61 2 9209 4172
www.forge.com.au

**********************************************************************
This message contains privileged and confidential information intended
only for the use of the addressee named above. If you are not the
intended recipient of this message you must  not  disseminate,  copy
or  take  any action  in reliance  on  it. If  you have received this
message in error please notify the sender immediately. Any views
expressed in this message are those of the individual sender, except
where the sender specifically states them to be the views of another
(including a Body Corporate).
**********************************************************************

---

---

From: Eric Rescorla <[email-masked]>
Date: 13 Mar 2001 15:35:35 -0800

> Until the trusted signer certificates expire, or are compromised and
Since we don't really have CRLs it's not like we really know how
to get rid of such certificates anyway.

> question, not just use an alternate certificate scheme.
I don't know of any other technique that will work here.

-Ekr

---

---

From: Pete Chown <[email-masked]>
Date: Wed, 14 Mar 2001 10:43:13 +0000

David A Taylor wrote:

> and then using a name/password later.

You could do this, but you are then vulnerable to active attacks.
(Protection from passive attacks is, of course, better than nothing.)

A more interesting application of ADH ciphersuites is to use TLS with
new authentication methods.  Provided the authentication method can be
tied to the TLS Finished message you achieve protection against active
attacks too.

For example, suppose you had a challenge/response authentication
system that you wanted to use with TLS.  With ADH you can do this.
The server sends the challenge to the client over ADH TLS.  Then the
client hashes the response and the Finished message, returning that to
the server.

-- 
Pete

---

---

From: "Raif S. Naffah" <[email-masked]>
Date: Thu, 15 Mar 2001 07:11:42 +1100

At 09:30 AM 3/14/01 +1100, David A Taylor wrote:
>...

that is not my impression;  i.e. people did not agree.  they certainly 
proposed, optional, ways of doing it "if it is wanted."  my understanding 
is that server authentication is as good with SRP password file as it is 
with a server certificate.  compromising the server's certificate is 
equivalent to that of its password file.

i'd leave the I-D as it is, but add a summary of this discussion.

if the argument of "increasing" security by adding certificate 
authentication to TLS-SRP holds, then it also holds both ways;  i.e. it is 
an added "security" to use SRP-style password authentication to 
certtificate based ones.

>question, not just use an alternate certificate scheme.

if to the question if in a TLS-SRP exchange (as proposed in the I-D) the 
server is authenticated the answer is yes, then you do not need to add 
certificate-based scheme(s) for this purpose.

my understanding of the discussion so far is that it is the case.

cheers;
rsn

---

---

From: David Taylor <[email-masked]>
Date: Thu, 15 Mar 2001 08:08:35 +1100

> to get rid of such certificates anyway.

So, there is not good method of retrieving trusted signer certificates, there is no good method of finding whether they are still valid once you have them, and there is no easy method of storing and managing them locally.

This does not sound like an ideal system to use for a security protocol. Users will get around difficult things any way they can, and getting around the difficult things regarding security probably compromises the security.

I don't see a compelling argument in favour of using certificates for server authentication yet.

> I don't know of any other technique that will work here.

And unless an organisation is willing to invest in hardware secrurity for their key pair, it is no more secure using a public key certificate to identify the host than it is the verifier file - in both cases all that is being claimed is that whatever host you've connected to has those files, not is the real host.

After all that, it seems for now we can say possesion of the verifier file is as good as possesion of the key pair, so there is no practical advantage to adding a server certificate to the handshake for SRP.

I would rather not have certificates in the handshake anywhere, and if we agree that key files are no safer than any other, it seems we can't rely on them anyway.

I think Eric started off by possesion of the verifier file was good enough, and Raif has pointed it out too (if I have put words in your mouth, correct me). How do other people feel?

Regards,
David.

---

From: Eric Rescorla <[email-masked]>
Date: 14 Mar 2001 13:25:45 -0800

David Taylor <[email-masked]> writes:

> [1  <text/plain; us-ascii (quoted-printable)>]
> 
> So, there is not good method of retrieving trusted signer
> certificates, there is no good method of finding whether they are
> still valid once you have them, and there is no easy method of
> storing and managing them locally.
>
>  This does not sound like an ideal system to use for a security
> protocol. Users will get around difficult things any way they can,
> and getting around the difficult things regarding security probably
> compromises the security.
>
As Churchill is supposed to have said about democracy, it's the
worst system that there is, except for all the others. Essentially,
certificates are indispensible when you're connecting to someone
you've never connected to before (as is the common case with HTTPS).
If you have a shared password they're not that big a win but they
still provide some degree of "belt-and-suspenders".

-Ekr

---

---

From: Tom Wu <[email-masked]>
Date: Wed, 14 Mar 2001 14:24:15 -0800

David Taylor wrote:
> And unless an organisation is willing to invest in hardware secrurity
> for their key pair, it is no more secure using a public key certificate
> to identify the host than it is the verifier file - in both cases all
> that is being claimed is that whatever host you've connected to has
> those files, not is the real host.

I think we have agreement on the point that without some extra means of
security for a server private key (like a hardware module), a server
cert doesn't buy any additional security over the verifier database.

> After all that, it seems for now we can say possesion of the verifier
> file is as good as possesion of the key pair, so there is no practical
> advantage to adding a server certificate to the handshake for SRP.
> 
> I would rather not have certificates in the handshake anywhere, and if
> we agree that key files are no safer than any other, it seems we can't
> rely on them anyway.
> 
> I think Eric started off by possesion of the verifier file was good
> enough, and Raif has pointed it out too (if I have put words in your
> mouth, correct me). How do other people feel?

I'm inclined to agree.  On the other hand, if you're going to do some
kind of explicit server authentication, you might as well use the
existing X.509 infrastructure for doing it, since you get to leverage
more code at both the client and server ends, not to mention the
availability of CAs.  I didn't really see any advantage to doing it any
other way.

I believe that the sweet spot for TLS-SRP will occur with
certificateless servers, since you get the benefits of strong
authentication and secure transport, without having to deal with certs
or PKI at all.  It boils down to whether having the
"belt-and-suspenders" choice available is worth the extra complexity in
the spec.

> David.

Tom

---