Subject: [TLS] SRP ?

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Feb 2016 15:34:39 +0000

Is anyone using SRP with TLS?  The OpenSSL implementation in particular?

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: John Foley <[email-masked]>
Date: Tue, 23 Feb 2016 10:43:09 -0500

Yes, Cisco uses this.

On 02/23/2016 10:34 AM, Salz, Rich wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Rick van Rein <[email-masked]>
Date: Tue, 23 Feb 2016 21:43:11 +0100

Hi,

> Is anyone using SRP with TLS? The OpenSSL implementation in particular?
We're considering it too, although not necessarily through OpenSSL.

Also I'd really prefer an ECDH-based formalism; I'm note sure if work on
that is being done, or where.

-Rick

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 24 Feb 2016 22:53:17 +0100

> On 23 Feb 2016, at 16:34, Salz, Rich <[email-masked]> wrote:
> 

I have been in the past and know of some installations and customers that actually use it.
Although the lack of modern cipher-suites for SRP makes it not very attractive these days.

Aaron

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Feb 2016 21:54:17 +0000

Thanks for the feedback, everyone.  The OpenSSL SRP code is staying.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 24 Feb 2016 22:59:45 +0100

Hi,

> Although the lack of modern cipher-suites for SRP makes it not very
Does anyone know if work on something like "ECSRP" is going on, anywhere?

We've recently worked on getting it working with PKCS #11,

https://github.com/arpa2/srp-pkcs11
https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf

It could be interesting to see if this translates to the Elliptic Curve
arena.

I heard rumours of alternatives being weighed against one another, but
failed to find anything concrete.  Links are quite welcome!

-Rick

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 25 Feb 2016 23:33:25 -0800 (PST)

Hi,

> failed to find anything concrete.  Links are quite welcome!

  Well there's TLS-PWD. Works just fine with ECC. Also provides
for protection of the client username from passive attack.

        https://tools.ietf.org/html/draft-ietf-tls-pwd-07

Thanks for reminding me to update that draft :-)

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 25 Feb 2016 23:41:39 -0800

>         https://tools.ietf.org/html/draft-ietf-tls-pwd-07

As well as my SPAKE2 draft, which can fit in TLS easily. The real
problem here is that there is no reason not to use certificates in a
lot of cases.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 26 Feb 2016 11:26:06 -0800 (PST)

> problem here is that there is no reason not to use certificates in a

  Well if you're using a browser I'd agree with you. But when TLS
is used to protect non-browser traffic there are plenty of cases
where you won't have an implicit trust anchor database or you're
going to some server administered by someone who most likely only
has a self-signed cert (Let's Encrypt makes it easy to get a cert
for a web server but, again, that's kind of browser-centric).

  I address the case for certificate-less authentication in section
1.1 of the TLS-PWD I-D.

  regards,

  Dan.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 26 Feb 2016 22:18:45 +0100

Hello,

g/html/draft-ietf-tls-pwd-

>> The real
> when TLS
> has a self-signed cert

+1

-Rick

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Feb 2016 14:00:54 -0800

>   I address the case for certificate-less authentication in section

The right solution is to make certificates easy. SSH solved this years ago.
(Yes, I'm aware devices don't necessarily have a "trust anchor". Passwords
assume enough input capacity to solve this probem.)