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 
when advertising SRP support, and must not proactively send an A value.  I'm 
suggesting making these both decision points for the client.

This adds more paths through the protocol and makes it more complicated.  I 
think it would still be manageable though, if you had protocol messages that 
could be optionally nested within each other like:

ClientHello
- ClientSRPParams     u,[g,N]
  - ClientKeyExchange  A

ServerHello
- ServerSRPParams     s,[g,N]
  - ServerKeyExchange  B

ClientSRPParams would be nested within ClientHello (i.e. attached as an 
extension) if the client already knows the username, is anticipating the 
selection of an SRP ciphersuite (perhaps because that's the only type the 
client offered), and wants to reduce a round trip in this event.

ClientKeyExchange would be nested within ClientSRPParams if the client is 
trying to anticipate acceptable group parameters in an attempt to reduce a 
round trip.

The server will ignore a nested ClientSRPParams if he doesn't choose an SRP 
ciphersuite, otherwise he will respond with a nested ServerSRPParams.

The server will ignore a nested ClientKeyExchange if the ClientSRPParam's 
group parameters are unacceptable, otherwise he will respond with a nested 
ServerKeyExchange (and omit his own group parameters from the enclosing 
ServerSRPParams).

So in the most nested case, the variables exchanged would be:
C->S: u,g,N,A
C<-S: s,B

And in the most expanded:
C->S: {hello, offers SRP ciphersuite}
C<-S: {hello, selects SRP ciphersuite}
C->S: u
C<-S: s,g,N
C->S: A
C<-S: B

Is this complexity worth the benefits?  Are there other, better ways to 
achieve the same goals?

I think the proactive A optimization is the less important thing here.  The 
ability to send the username after negotiating an SRP ciphersuite seems more 
significant to making TLS/SRP useful with legacy protocols.

Trevor

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com