Subject: [TLS] draft-barnes-tls-pake

From: Rob Sayre <[email-masked]>
Date: Tue, 3 Sep 2019 16:04:51 -0700

Hello,

I read https://tools.ietf.org/html/draft-barnes-tls-pake-04.

I understand and agree that the SRP scheme in RFC 5054 might not apply
cleanly to TLS 1.3.

However, I don't understand the rationale for choosing other PAKE
algorithms for this draft over SRP. I found that Apple iCloud and HomeKit
use SRP, so it seemed strange to choose other algorithms in this draft,
given the popularity of those products.

I'm not pushing an agenda here. I just want to understand. But, I found the
rationale in the various draft-barnes-tls-pake drafts very unenlightening.

thanks,
Rob

---

From: Björn Haase <[email-masked]>
Date: Wed, 4 Sep 2019 10:39:11 +0000

Dear Rob,

you might know that currently there is an ongoing PAKE selection process in the context of the CFRG working group. SRP is no longer considered there.

In my opinion, SRP comes with several problems. It’s patent circumvention approach did consider patents that today are expired. This patent circumvention made 1.) the protocol computationally very complex and 2.) prevented through security analysis/proofs. (See e.g. the discussion in  https://eprint.iacr.org/2018/286 in section 2.1.).

Regarding the complexity: I did analyze SRP once for the computational constraints of the setting https://eprint.iacr.org/2017/562. There SRP would have resulted in about two minutes (120 s!) login delay for 1024 bit field size (80 bit symmetric security level) because of the complexity of the computations on the constrained embedded server.
With today’s alternatives (see, e.g. https://eprint.iacr.org/2018/286) using Montgomery or Edwards curves, you could realize 2-4 seconds for the 128 bit security level for the very same constraint setting.

So for security-proof reasons and for efficiency for embedded devices there is a need for alternative PAKE protocols. There draft-barnes-tls-pake describes one out of several possible approaches.

Yours,

Björn

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

Von: TLS <[email-masked]> Im Auftrag von Rob Sayre
Gesendet: Mittwoch, 4. September 2019 01:05
An: [email-masked]
Betreff: [TLS] draft-barnes-tls-pake

Hello,

I read https://tools.ietf.org/html/draft-barnes-tls-pake-04<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-barnes-tls-pake-04&data=02%7C01%7Cbjoern.haase%40endress.com%7C0dd3e93d68f84993d53d08d730c33ea0%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637031487436897945&sdata=4UZhHwWpFl%2Bg1R3Ocoz7JbJ2NKndciKI3eDLvcpboQg%3D&reserved=0>.

I understand and agree that the SRP scheme in RFC 5054 might not apply cleanly to TLS 1.3.

However, I don't understand the rationale for choosing other PAKE algorithms for this draft over SRP. I found that Apple iCloud and HomeKit use SRP, so it seemed strange to choose other algorithms in this draft, given the popularity of those products.

I'm not pushing an agenda here. I just want to understand. But, I found the rationale in the various draft-barnes-tls-pake drafts very unenlightening.

thanks,
Rob

---

From: Rob Sayre <[email-masked]>
Date: Wed, 4 Sep 2019 12:36:21 -0700

On Wed, Sep 4, 2019 at 3:39 AM Björn Haase <[email-masked]> wrote:

> Dear Rob,
>
> you might know that currently there is an ongoing PAKE selection process
> in the context of the CFRG working group. SRP is no longer considered there.
>

Well, that list is way over my head. Thank you for pointing it out, though.
Here's the mail archive for anyone interested:
https://www.irtf.org/mailman/listinfo/cfrg

>From the list archives, I can see that there's a PAKE evaluation contest
running right now, but I can't actually find a web page about it (something
that might list the candidate algorithms, for example).

> In my opinion, SRP comes with several problems.
>

I hope the PAKE contest details the reasons for the rejection of each
algorithm.

thanks,
Rob