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

[Björn Haase <[e-mail]>]

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: [phone] | Fax: [phone]
[e-mail] |  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 <[e-mail]> Im Auftrag von Rob Sayre
Gesendet: Mittwoch, 4. September 2019 01:05
An: [e-mail]
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