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

Natanael <natanael.l@gmail.com> Wed, 28 August 2019 09:31 UTC

Return-Path: <natanael.l@gmail.com>
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 A151512009C for <cfrg@ietfa.amsl.com>; Wed, 28 Aug 2019 02:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.com
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 e4Z1K5OIHWVt for <cfrg@ietfa.amsl.com>; Wed, 28 Aug 2019 02:31:46 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A8D120096 for <cfrg@irtf.org>; Wed, 28 Aug 2019 02:31:46 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id m62so1401477vsc.8 for <cfrg@irtf.org>; Wed, 28 Aug 2019 02:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=suDdWnvheIn3mcnZGFFoDn2pA34My4ye2IXq0l0eLk8=; b=hdLGZxpBMdy0Hu1x6TQ7prSXLnKtN0DUXyM/naO3ndTPSFrQrMXsKRZQMsf21QpKVQ jYwpqPAkLJ9cm6SA4vlqk5Gg7p27eNQb/YNdJtS1dYDE1F43w80vPwMaZ7YeEz+7BzCz OiZ+mJervnnQqHZLhdg6L3cRjuCG/LTXYuYFw2sAj4+GDxIO6mZ1gYpDpHcUBlDubD8N lnOW0ZAnaP8oruIzr/gGrQZphjEhkeFWezA+VaFMetxXDNePY8OItnXRFWsVu8KVGzEf vP38yf86C6eEo/rBuWuT6UZSiXp6AzfYbEyHDEZO7oTsRqLJiMhvg7ThS3msKknqZzUW lBdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=suDdWnvheIn3mcnZGFFoDn2pA34My4ye2IXq0l0eLk8=; b=BE/+Rqwn7jy+ZJR10w2FhcNMeS4aFC/UwnQOU9PveIxOqrz3eMEimd++CB8Xc5zRyQ aPwUXzPjfp68esLdtzQNXLL+l/F60C/RyBXd4QnDORbLfIdZRTl13jyXXlmq4If3R+ys LTXpkAIznqKNfPfXiI07DiPi7oUBqhe0Jl8S4SXLcp2xexeA6rbA5Q5pysK+iNv8wAiz +xHXHXioAgaEAUSHoix1Y1moqhi4YEfQifJOO/zP1SfTBB2kAKu1VyfMmTWax+jw7rwK T9uIKz5Cum3mncuczvEmDFi70JWM4Yo6G1x8j1xusxcagLN26nsXQyyjPR0LWKFGfB/q DBgQ==
X-Gm-Message-State: APjAAAW8HdImVrBBKoebYZmh1HqM9njgLaZEDT47SYuAk6IBM/LFSDKt IuKpXUjyhC4yuO4BoPuH+MYSQAT1+wKM43psoj8=
X-Google-Smtp-Source: APXvYqwKEcyeigyM1IIpQoLHiZQv3w1n0bM5Jdeey5k9HbQsRXuBgzmv/uqMlTkPWyj6bGKqqD2GgqoqPtIp60ZIhoo=
X-Received: by 2002:a67:da1e:: with SMTP id v30mr1770276vsj.209.1566984705498; Wed, 28 Aug 2019 02:31:45 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <AM0PR08MB5345FC99B3EABBBF6EFD2353FAD40@AM0PR08MB5345.eurprd08.prod.outlook.com>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 28 Aug 2019 11:31:30 +0200
Message-ID: <CAAt2M18UMK0Xd-38napj=zCGv2dgQZwLEMt3rK47bRU2RDbDUw@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Jonathan Trostle <jonattr@gmail.com>, "Owen Friel (ofriel)" <ofriel@cisco.com>, "hugokraw@gmail.com" <hugokraw@gmail.com>, =?UTF-8?B?QmrDtnJuIEhhYXNl?= <bjoern.haase@endress.com>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000bd626505912a0efd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/dNQ0MQoQMPlyPhoMBD48KdmG_ss>
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.
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, 28 Aug 2019 09:31:49 -0000

Den ons 7 aug. 2019 14:16Hannes Tschofenig <Hannes.Tschofenig@arm.com>;
skrev:

> 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…
>
We just got Facebook declaring interest in using OPAQUE or equivalent PAKE
protocols, which is significant.

And I also think (in my layman's opinion) that this should be supported in
browsers so websites can use it. I've written this once before;

The way I see it, combining a PAKE with a 2FA solution like FIDO / WebAuthn
is the best approach.

It's infinitely more resistant to both phishing and to accidental harm.
Compared to just adding a second factor which would still expose the
password, you don't just devalue credential phishing attempts when
combining U2F + PAKE, you can make it close to impossible.

FIDO 2FA by itself doesn't really "tackle the password problem". It "just"
adds a very strong shield *behind* it (but not in front of it). You still
risk leaking passwords, and password reuse isn't going away no matter how
much we try, people will remain lazy and reuse them. And not every site
will use 2FA!

While it's true that a PAKE can't protect a weak password if the server
gets breached (dictionary or bruteforce guessing), it can however protect
against a hacker spying on your strong passwords when they hack a site you
use! So under PAKE, your strong passwords remain strong even if the
adversary can manipulate the server, and they won't be able to test reusing
then against other services (at least assuming replay attack protection in
the protocol!).

A secondary and less common risk (yet real) is spearphishing, where
somebody is willing to steal your token and test reused passwords against
the target web service(s).

Pushing for widespread PAKE support (with dictionary attack resistance) to
resist password leaks is far more effective. One could hope that training
users to expect a browser initiated PAKE password entry would make them
suspicious of plaintext credential phishing forms.

I envision an approach where the user first types their username (which the
browser can remember), get asked to confirm their login attempt with their
hardware 2FA token (button press, or TPM connected secure input), and then
they get a secure PAKE prompt from the browser that asks the user to type
their password / PIN. After both U2F and PAKE has successfully
authenticated the user, they get logged in.

The browser's PAKE prompt may even be integrated with a password manager,
so you only need to click OK after you have unlocked your password manager.

U2F even supports registering keypair on the hardware token which allow you
to login without typing your username (requires using storage space on the
token), making it even simpler (press the button, type a PIN).

So the simplest secure login ux flow would be to unlock the password
manager once with your password, then login to a website by tapping the
hardware token's input button, then (optionally, can be automated) confirm
your password input.

>
>