There is also the OPAQUE-specific https://tools.ietf.org/html/draft-sullivan-tls-opaque-00 which Nick presented at 104: https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00
Owen -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Benjamin Kaduk Sent: 21 July 2019 05:12 To: tls@ietf.org Subject: [TLS] Fwd: [Cfrg] PAKE selection process: Maybe we need a modular approach for integrating authentication of human individuals with TLS? Björn wanted to give folks a heads-up for thinking about potential TLS-PAKE integrations (I note that draft-barnes-tls-pake-04 has expired). -Ben On Fri, Jul 19, 2019 at 09:45:03AM +0000, Björn Haase wrote: > Hello to all, > > I am writing this mail in order to prepare the future steps regarding PAKE on > and after the Montreal Conference. > > My personal perception is that among the set of current nominations no > protocol was proposed that is obviously inadequate. (I personally am somewhat > sceptic regarding the proof situations for “SPAKE2+EE/BSPAKE” and “SPEKE”, > but even for these two I don’t see obvious flaws if integrated properly.) My > expectation is that regarding the security-topics, we might reach consensus > in the CFRG community quite easily, once we have established a common > understanding of the design priorities regarding patents, round efficiency, > computational efficiency and security-guarantees. > > I believe that the main objections regarding PAKE will come from elsewhere: > The people that would have to integrate it into larger systems like TLS, > browsers, OS or password database management modules (such as PAM). > > I see the urgent need to standardize a sound PAKE for human user > authentication and I think that for this purpose we will need to consider the > concerns and needs of the “system integration” people very seriously. > Otherwise, we might not be successful with the project of improving security > and usability. > > When trying to “wear the hat” of these people, I came to the conclusion that > we might need some kind of a modular system integration approach. I have > spend quite some time and discussions on this topic. I would appreciate your > feedback regarding the problem analysis and solution approach that I tried to > summarize in the slides available at > https://github.com/BjoernMHaase/fe25519/blob/master/Concept_For_Modularized_PAKE_integration_into_TLS.pdf > . > > Maybe somebody might also spread this link to the TLS working group people or > discuss the topic of TLS integration of PAKE at the upcoming conference in > Montreal. (There seems to be an issue with my mail accounts being blocked > from posting to the TLS mailing list ☹). > > I am looking forward to entering a discussion with you. > > 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 > Endress+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. > > _______________________________________________ > Cfrg mailing list > c...@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
