TLS/SRP suggestions

It would be nice if the client could offer the SRP ciphersuites in the 
ClientHello message, but without committing to a username.  This would let a 
client application using TLS to protect SMTP, POP, HTTP, etc., advertise its 
ability to do SRP to a server, but only go ahead and prompt the user to 
enter his username (and password) when the server selects the SRP 
ciphersuite.  On the username/password dialog there might be a checkbox 
saying "always use SRP authentication for this server in the future".  The 
user could select it and from then on, if an active attacker tries to spoof 
the server and denies he supports SRP (ie tries a downgrade attack) the 
client application would warn the user.

This would be a good way of  bootstrapping use of SRP mutual auth within 
legacy protocols, because the fact that two endpoints support SRP would be 
naturally discovered in the course of TLS negotiation.  Otherwise, with the 
current protocol, the client would need some application-specific or 
preconfigured knowledge of when to engage in TLS/SRP and when not to.

As a separate issue, an optimization would be for the client to make a guess 
about which group parameters g,N might be acceptable to the server, and 
proactively send a value of A calculated using these to the server.  The 
server could always refuse to accept this value and send back the values of 
g,N he does accept, forcing the client to generate a new A.  But in cases 
where the client chooses correctly, a round-trip is removed from the 
handshake protocol (from 3 to 2).  The TLS/SRP document could suggest a 
number of default group parameters choices, at different levels of security. 
  Also, a client could remember the group parameters acceptable to a 
particular server, so as to exploit this optimization next time.

So in the current TLS/SRP draft, the client must proactively send a username