[TLS] Fwd: [Cfrg] PAKE selection process: Maybe we need a modular approach for integrating authentication of human individuals with TLS?

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 July 2019 04:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8511200C3 for <tls@ietfa.amsl.com>; Sat, 20 Jul 2019 21:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1a3VSvM0EGz for <tls@ietfa.amsl.com>; Sat, 20 Jul 2019 21:11:46 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7A112006A for <tls@ietf.org>; Sat, 20 Jul 2019 21:11:45 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6L4Bfh1025425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sun, 21 Jul 2019 00:11:44 -0400
Date: Sat, 20 Jul 2019 23:11:41 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: tls@ietf.org
Message-ID: <20190721041140.GT23137@kduck.mit.edu>
References: <VI1PR0501MB2255752B38545BA82261F20383CB0@VI1PR0501MB2255.eurprd05.prod.outlook.com> <VI1PR0501MB22552132C0FE682841A9CAFB83CB0@VI1PR0501MB2255.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <VI1PR0501MB22552132C0FE682841A9CAFB83CB0@VI1PR0501MB2255.eurprd05.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cwZqtgDaD12aoGtWi9Rsk2E60Os>
Subject: [TLS] Fwd: [Cfrg] PAKE selection process: Maybe we need a modular approach for integrating authentication of human individuals with TLS?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 04:11:48 -0000

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 Gerlingen | Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> bjoern.haase@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
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg