Subject: Re: [TLS] Comments on PR #95

From: Tom Wu <[email-masked]>
Date: Wed, 7 Jan 2015 13:40:56 -0800

> Line 1912: Was anyone using SRP? The more generic we have to make TLS 1.3, and the more we > have to shoehorn in, the more complex it gets.
> This open issue could get hairy.

SRP is definitely useful, as it's the only PAKE ciphersuite available in TLS.  What exactly are the interactions that need to be worked out with PSK and SRP?

Tom

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 8 Jan 2015 00:36:26 +0200

On Wed, Jan 07, 2015 at 01:40:56PM -0800, Tom Wu wrote:
> > Line 1912: Was anyone using SRP? The more generic we have to make TLS
> > 1.3, and the more we > have to shoehorn in, the more complex it gets.
> SRP is definitely useful, as it's the only PAKE ciphersuite available
> in TLS.  What exactly are the interactions that need to be worked out
> with PSK and SRP?

AFAIK, There issues are:

1) None of the groups defined for TLS are compatible with SRP.
2) Server will encrypt first (in TLS 1.2, client encrypted first).
   This may have cryptographic implications on SRP (and those are
   beyond my ability to analyze).
3) PSK has identities and identity hints.

A solution for 1)

If server selected SRP ciphersuite, it deems client to have missed
a group guess. The message about this includes the SRP group
parameters, and client then transmits its nonce public key
(with some fixed group number, the server knows the group).

A solution for 3)

If server selected PSK ciphersuite and client asked for a hint,
deem client to have missed the group guess. The message about this
includes hint about the identity. The client then transmits its
final identity (if doing "remedials", one could perhaps just
miss the identity and transmit it as a special handshake message).

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 7 Jan 2015 18:36:22 -0500

> SRP is definitely useful, as it's the only PAKE ciphersuite available in TLS.  What exactly are the interactions that need to be worked out with PSK and SRP?

SRP in TLS is inherently 2-RTT as implemented now: the client sends a
username, the server a key exchange response, and the client its
response, at which point a key can be computed. But the server sends
parameters that client uses for the exchange in their message. It may
be possible to change this, having the client pick the group, send
identity and A in the first message, and server respond with
everything else for the PMS in the second message. Doesn't help with
identity hints.

Sincerely,
Watson Ladd