Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

"Martin Thomson" <mt@lowentropy.net> Wed, 07 August 2019 12:54 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA912007C for <cfrg@ietfa.amsl.com>; Wed, 7 Aug 2019 05:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=cLQ7U2vD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uERffDlO
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 dh7tSahapq98 for <cfrg@ietfa.amsl.com>; Wed, 7 Aug 2019 05:54:18 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DEA12004D for <cfrg@irtf.org>; Wed, 7 Aug 2019 05:54:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 00C8E47B for <cfrg@irtf.org>; Wed, 7 Aug 2019 08:54:17 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 07 Aug 2019 08:54:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=sTFoY KuHaPZ4fF3v6apyHf9LOi5KKTi8xxD0prP1qIQ=; b=cLQ7U2vDcNK5OUO8wo3Dn Xl1GTKqvYOM/hGvgkid4Uw9CgAa365nL+5ozjnfMiwRRoZFApH9CdfDJsIinm8Jv LvnJMd/Ly6qTFj/8iDDX+ZtXLEGMRFjeX4/tNhdrvvjeUrB58yu47QqJrIWrTixd LP0LxrnSaDmxj7gi4kHO6nXY9oTD7JRAr3REZQZ5Xrv7t6YNTteCGM4Ge+etXFF6 ncyhQapdrolIZqQXLc8MHY12DpMCh1MT04wpor6YIx8Z5x3iW/KsZw4lc/0di4Dy CxxelvVq/hjr0KOMfhDkfAaMWbSan+fb3E9VFBcoI7EwCU7mMk9DjHJxjTby80aZ A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=sTFoYKuHaPZ4fF3v6apyHf9LOi5KKTi8xxD0prP1q IQ=; b=uERffDlOzQ/62jQsc0UVO158aNvdxYiL12hTVNVBbeKW0tNiVIy016duH COazJPJdUMweaecqaWnz6hvD5veAAdf5OUu65KbRfwk7wzMw9cauli0n8FZnmF8U KlrXQhs9//A68Q5OePF4lfTRPbjQJsP0vMDlA+ZckuAAkBWH3BA5PWcEkKj1L0nH ekXhC0bEau6XNklXGAUmeLwxy/zheRMh7Yrr79w0n5FFjLOkUVs3jE9KC7hB/I8d 3064hMh155kniujZKgmZnVQUuT1w9+WQRkdcnCFUuWwVzpuF1M1QNGHFG5srkoDV ztXdUfKDqH3h9j4EbjmL0Ssu1cr9Q==
X-ME-Sender: <xms:-clKXf5R2R-D7KNvwsEmNuregHdBxI3J2hg4Idy94rIi3ZK8f0ljTg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpihgvth hfrddrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:-clKXZ6Hb3ZOh-hbmSVQC8Cp1C86XOMOma8bbv_wFGTc8Ugxyw-aQg> <xmx:-clKXeX_0uc0gbrROEMrvwfB0wFRGpP8eM6BcEGtpW-G3YJ-B2DckQ> <xmx:-clKXd8G3lAQXrUO5BlSoLkqFtCLG3df4Qr6oG14dA11GK2-r7AXiw> <xmx:-clKXaXFGS9ZSusC0zhcLqj-KxNb8v2CIRQYAAGetfXevaLU-YCqaQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1F520E00A2; Wed, 7 Aug 2019 08:54:17 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2
Mime-Version: 1.0
Message-Id: <85d5c5f7-89c7-42ae-9c5a-2ccb359a6fed@www.fastmail.com>
In-Reply-To: <AM0PR08MB5345FC99B3EABBBF6EFD2353FAD40@AM0PR08MB5345.eurprd08.prod.outlook.com>
References: <VI1PR0501MB225515FC68BD4CBF7C6F904E83C50@VI1PR0501MB2255.eurprd05.prod.outlook.com> <CACsn0ck3AhxHeu6=vAf9CMNLJcjkC59jhWDdGD-RP03DNqCfXA@mail.gmail.com> <20190723042811.GL99187@kduck.mit.edu> <VI1PR0501MB225501B52DC40DC41E6D590683C70@VI1PR0501MB2255.eurprd05.prod.outlook.com> <DM6PR11MB33855C114392B1A400D4C0B2DBC70@DM6PR11MB3385.namprd11.prod.outlook.com> <CAB+1-SckMT6oSJPbuM4fvWqC+8vGVUSYg-qTMt+i4EHBbbn64A@mail.gmail.com> <AM0PR08MB5345FC99B3EABBBF6EFD2353FAD40@AM0PR08MB5345.eurprd08.prod.outlook.com>
Date: Wed, 07 Aug 2019 22:54:13 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: cfrg@irtf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5YB6LbdXY0EVY5-tvPQoHzSAc58>
Subject: Re: [Cfrg] =?utf-8?q?How_to_circumvent_the_obstacles_for_PAKE_integr?= =?utf-8?q?ation_into_TLS_//_slides=2E?=
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 12:54:21 -0000

FWIW, as a browser, these "iot" cases - enrollment and the like - are more what motivate us than the augmented ones. For example, we're interested in using low entropy values in pairing new browser instances, and setting up debugging sessions with things like VR/AR headsets, which have limited interfaces. 

On Wed, Aug 7, 2019, at 22:15, Hannes Tschofenig wrote:
>  
> Here are my 5 cents: 
> 
> 
> I don’t expect PAKEs to be used for web-based scenarios as a 
> replacement for passwords used in web-based applications. 
> 
> Instead, the only use of PAKEs I had seen over the last few years was 
> in the area of IoT as part of onboarding mechanisms.
> 
> 
> Unless those folks developing browsers tell me that they want to put 
> PAKEs into their browsers I would focus on the IoT use cases instead. 
> The reason why I am saying this is because FIDO, which also tackles the 
> password problem, looks like a much, much more promising route…
> 
> 
> Ciao
> 
> Hannes
> 
> 
> *From:* Cfrg <cfrg-bounces@irtf.org>; *On Behalf Of *Jonathan Trostle
> *Sent:* Mittwoch, 7. August 2019 06:29
> *To:* Owen Friel (ofriel) <ofriel@cisco.com>;
> *Cc:* Björn Haase <bjoern.haase@endress.com>;; CFRG <cfrg@irtf.org>;; 
> hugokraw@gmail.com
> *Subject:* Re: [Cfrg] How to circumvent the obstacles for PAKE 
> integration into TLS // slides.
> 
> 
> A good future goal is to eliminate plaintext passwords being sent over TLS.
> 
>  So a future TLS implementation based on a config setting, could abort 
> a TLS handshake if there is no preshared key authentication or 
> certificate verify sent by the client. It seems the OPAQUE-sign option 
> (in the TLS Opaque draft) supports this but the Exported Authenticators 
> do not.
> 
>  It seems difficult for a TLS client to know which of Exported 
> Authenticators with OPAQUE or plaintext password over TLS is being used.
> 
>  Best regards,
>  Jonathan
> 
> 
> On Tue, Jul 23, 2019 at 8:29 AM Owen Friel (ofriel) <ofriel@cisco.com>; wrote:
> 
> > Björn, 
> > 
> >  Its worth reading  https://datatracker.ietf..org/doc/draft-sullivan-tls-opaque <https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque> which Nick presented at 104:  https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00. It covers both OPAQUE in the TLS handshake, and OPAQUE via Exported Authenticators  https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ at some point after TLS handshake has taken place. Its currently OPAQUE specific, but the EA model could probably be applied to other PAKEs. And finally,  https://datatracker.ietf..org/doc/draft-ietf-httpbis-http2-secondary-certs/ <https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/> covers how to use EA with HTTP2.
> > 
> >  Owen
> > 
> >  -----Original Message-----
> >  From: Cfrg <cfrg-bounces@irtf.org>; On Behalf Of Björn Haase
> >  Sent: 23 July 2019 08:43
> >  To: Benjamin Kaduk <kaduk@mit.edu>;; Watson Ladd <watsonbladd@gmail.com>;
> >  Cc: CFRG <cfrg@irtf.org>;;  hugokraw@gmail.com
> >  Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.
> > 
> >  Dear Ben,
> > 
> >  >To build on that, a big motivation for wanting auth at the HTTP layer 
> >  >is that most generic web servers aren't going to know *at TLS handshake 
> >  >time* whether a given client is going to need to authenticate for the 
> >  >HTTP requests that will subsequently be conveyed over that connection.
> > 
> >  I fully agree. When saying this, I think that we might better be careful not to mix-up two aspects:
> > 
> >  1) The human at the client side mostly wants to be sure that the server side contents are authentic, from the very beginning.
> >  2) The server side requires authentication often only when operations with privileges are requested.
> > 
> >  What we have here is something similar to what I'd be calling "re-authentication use-case" for password checks in a connection that is already established.
> > 
> >  Moreover I see differences regarding the use-cases A "End-customer-managed web servers (IoT)" and B "Conventional Web-Shop use-cases (Web-PKI)". The main additional benefit of PAKE for use-case A is that the server-authentication (1.) above) is provided also without the need of Web-PKI integration of the server.
> > 
> >  I think that one might best try to realize the maximum possible re-use for authentication mechanisms in both use-cases A/B. Again this might be a reason for "outsourcing" all of the user-handling related stuff outside of the main TLS body. Also for use case "B" it might be worth to consider pulling out the password handling out from the main html application. Maybe one could use the same mechanisms of a "user authentication" module that we would be using for PAKE? For doing so again some kind of channel-linked tunnel mechanism through TLS might be helpful/necessary.
> > 
> >  Yours,
> > 
> >  Björn.
> > 
> >  P.S.: I have moved this discussion back to the main list. Sorry for starting this discussion with the "not yet publication-ready" slides.
> > 
> > 
> >  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 
> >  Endress+| 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
> >  _______________________________________________
> >  Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
>  IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you. 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>