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 bjoern.ha...@endress.com | 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 <tls-boun...@ietf.org> Im Auftrag von Rob Sayre Gesendet: Mittwoch, 4. September 2019 01:05 An: tls@ietf.org 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
