Re: [Cfrg] aPAKE Analysis
Jonathan Hoyland <jonathan.hoyland@gmail.com> Mon, 23 September 2019 13:21 UTC
Return-Path: <jonathan.hoyland@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 E9824120809 for <cfrg@ietfa.amsl.com>; Mon, 23 Sep 2019 06:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 yRlYUr7W36Hr for <cfrg@ietfa.amsl.com>; Mon, 23 Sep 2019 06:21:47 -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 53CB6120105 for <cfrg@irtf.org>; Mon, 23 Sep 2019 06:21:47 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id b1so9363938vsr.10 for <cfrg@irtf.org>; Mon, 23 Sep 2019 06:21:47 -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=+MLZYCVx8kgPP20BCkD+bAAtuMS98y+kcNL2WsoBH2s=; b=EYZCdyHR9RQEJYAu35mOLUDEE63saV4S1Xu2bOhDKHoYurZ47LTcYTUrGttJ/SiI0A tmWQxT3e+h2XEMP4T8VeQjECfiEo9POqE7ExI216U/8cN6ugvOxB6JD6Ec9Hp3mETZyd 9dKll2Q/81S8IHXz/7CUVavtASYBfaT3Rkita9uwzBv+QmLdWF2+ZTVZc6FmUi21VXWT TMrxHAmXN3WEuXpxf7Rp/QJ9Agp4IBMEpHyZ+UxnBTf1tyBRiEoPbed9zO9b8nxXLkAo cKeFXcDK34B12SNdkFL8F7rprPf78rb8+mJH2hi/+F8jlREOTZ6Hj4MotA+v4riA+uHl 8gFw==
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=+MLZYCVx8kgPP20BCkD+bAAtuMS98y+kcNL2WsoBH2s=; b=kOZwMvwG0H7SS4jhE3pNTJAECSmxxB0/WL1O1eoS/goXs0SYSAkWg1GfOJGs+QVAwK 0iEVkHyI5NbfkYYYbqy15z2L2N8xs0YrFTef4aFI3qroLbhhCsrMqSaAr6lc3r8+H8/p w4YisQ5O19RFKQ+lUIXZOhMrNKEA1wOqPwr0YOKEa/vIEA9abfK5FeEVDtppxkEB4WB4 aEdSl9KOfwXXuwwxdKTVmXZoaMTNcx0u5iLGFxB4DVHOTM64JnMqATbQAh2qwpZ3Xaf4 Ezs5ENo6ZsLBFLqXTijKR4UkQucE2x7wBJy2mvzvC9GDz10txihsmhqJgWDqKCW6yKWe la4g==
X-Gm-Message-State: APjAAAXRy9lTd4l/ntYPTC9BWo1dZCKB4mb0HhM2/kewH+wq0RBajNEw aV7zJKhJpOqUATN8VwFwcROqkT/nSBJiraCV8qo=
X-Google-Smtp-Source: APXvYqxzueL06idOt8HuAy7GXaKfjQS1RFFQwbo1j5xyUPpTxyD6Yiph+GqbtAfT1CwCmnHd+FTAnFrSYwRaSxaAvA8=
X-Received: by 2002:a67:6542:: with SMTP id z63mr10103936vsb.143.1569244906185; Mon, 23 Sep 2019 06:21:46 -0700 (PDT)
MIME-Version: 1.0
References: <1000404210.104219.1568701269003@email.ionos.com> <CACykbs3Bk40DpPb56SRXZJMHstUQqsT-n-Gkntrb0bhNss=zPw@mail.gmail.com> <CADi0yUPMiMdgZa8k7bP5wW_bVqxoMFXaJp0u1r7ZFRVaEfZOSg@mail.gmail.com> <CACykbs0mDkgfY=3=Wd0F=w7YwXYs9bEXJyhdcM74CEvw7w6-=Q@mail.gmail.com> <568ba75e-26fd-8b12-5974-67517bce23a4@web.de> <CACykbs0Pq=w4catZNBM0TC16RmL+Ytmy_VhXfTTpWRMnKkSoZw@mail.gmail.com> <VI1PR0501MB22552B1FA70101AFD48837DA83850@VI1PR0501MB2255.eurprd05.prod.outlook.com>
In-Reply-To: <VI1PR0501MB22552B1FA70101AFD48837DA83850@VI1PR0501MB2255.eurprd05.prod.outlook.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Mon, 23 Sep 2019 14:21:34 +0100
Message-ID: <CACykbs1jFUWRevk=OwKE6at-b486+wTnCeCTm10ao7x0q8KkEg@mail.gmail.com>
To: Björn Haase <bjoern.haase@endress.com>
Cc: Björn Haase <bjoern.m.haase@web.de>, cfrg <cfrg@irtf.org>, Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary="00000000000032ea410593384d2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/wGTCGk231Q6GLceUZRzQ6JaW3eY>
Subject: Re: [Cfrg] aPAKE Analysis
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: Mon, 23 Sep 2019 13:21:50 -0000
Hi Björn, I agree that OPAQUE + EAs is a Web-PKI specific mechanism, but that is not the only method for using OPAQUE with TLS. Specifically when you are doing website login then you should use a mechanism adapted for website login, but for non-Web-PKI scenarios you would use one of the other modes, for example OPAQUE-3DH or OPAQUE-Sign, etc. More precisely, in a scenario where you are using the Web-PKI, you need to carefully make sure that what the Web-PKI is telling you is consistent with what the PAKE is telling you. aPAKEs are at their core authentication protocols, and when they are used with other authentication protocols you need to make sure the combined guarantees are precise and in line with what people expect. If you aren't using the Web-PKI then obviously this isn't a concern, but if you are it has to be addressed. Defining browser chrome that indicates you are using an aPAKE would be great, especially if it integrated well with password managers, but that doesn't preclude using OPAQUE, it would make it even better. Irrespective of the security of how the page looks, consider the UX for AuCPace when used with a website as proposed. Imagine I go to, for example, https://nytimes.com, where I sometimes leave a comment. Before I can even see the headlines I have to decide whether or not to log in. If I decide not to log in and then change my mind, I have to tear down my TLS connection, start a new TLS session with a full HRR handshake, and reveal my username to even passive adversaries. For OPAQUE + EAs the flow is virtually indistinguishable from what we have now, perhaps with some nice browser chrome to indicate that an aPAKE is in use. If you are using TLS on a non-Web-PKI site, for example some IoT device configuration portal, then OPAQUE-Sign would have the same UI as AuCPace but wouldn't require the HRR, fitting into the standard TLS flow. To my mind, OPAQUE is better than AuCPace for use with TLS when interacting with the Web-PKI, which will (hopefully) be a major use-case. That's not to say that AuCPace wouldn't be workable, but obviously I'd prefer to use the best available option. What do you think are the most significant advantages of AuCPace over OPAQUE-Sign for IoT / non-Web-PKI use-cases? Regards, Jonathan On Mon, 23 Sep 2019 at 12:46, Björn Haase <bjoern.haase@endress.com> wrote: > Hi Jonathan, > > > > we seem to have very different use-cases. > > > > >You write on slide 22 that the user expects the dialogue immediately on > the Hello Retry, > > >but very few users will be familiar with that flow. > > >They expect to see a fully rendered page with two boxes in which they are > to type their > > >username and password, not an undecorated pop-up. > > > > Indeed what I am suggesting is to have this login page displayed as part > of browser controls or even better by OS or a password manager’s controls > and not by the remote server’s html. > > > > I could imagine that one possibly could add some small SVG icon on the > login screen (that’s what we do for our E+H Bluetooth app) but indeed the > login window might be rather un-decorated, as it is part of the browser > GUI/skin. Making it part of a window external to the https:// main > application region could also be considered a security feature. The > end-user could more easily distinguish a control from the browser/OS from > what is shown in the browser application. > > > > A user might even choose his own skin (unknown to the adversary) of the > window, making phishing attacks more difficult. The attacker would have to > find out, how the specific user’s login window looks like. > > > > In our setting this would be perfectly suitable from a usability point of > view. > > > > Also one of our main problems is that we could not expect the server to > have any valid Web-Certificate installed! Thus, for some IoT device for > which a web certificate was not bought and maintained, we would just not > have the option to establish any https:// connection through the normal > WEB-PKI certificate process! A well-configured browser would just not allow > for a connection! > > > > >Training users in this system will also make them more vulnerable to > malicious sites that render a >blank page and throw a pop-up asking for a > username and password. > > > > I don’t see that there would be any need for “user training” for the > “login window in browser” feature. Moreover a site screen should (IMO) not > be considered to provide **any** security feature. Any “reasonable” > attacker would make his fishing web page look just like the honest server! > > > > >From a user's perspective, they go to a website that renders normally, > and then they then login using >a username and password box. > > > > As mentioned before this approach mandatorily requires a valid Web-PKI > certificate in the first place. Secondly this approach would allow an > attacker to just use a normal http:// GUI control for standard > un-protected text for fishing the password. How would the user be able to > distinguish a web page that sends the clear-text password directly to the > server from a page that uses a secure aPAKE? > > > > In my opinion a solution using a specific browser or OS-based GUI window > for the login could be made more secure. A small site icon might be fine, > but this could possibly even be sent by the server in its HelloRetry when > using an appropriate compression format such as SVG. > > > > The main problem that I see with your suggestion is that it works only, if > the server has a valid trusted Web-PKI certificate **in addition** to the > aPAKE solution. > > > > This might be the case for some “conventional” Web-Applications, but not > the case for de-centralized Web servers in IoT devices (e.g. a control > valve in an industry installation or some household IoT equipment). > > > > 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.de.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] aPAKE Analysis steve
- Re: [Cfrg] aPAKE Analysis Jonathan Hoyland
- Re: [Cfrg] aPAKE Analysis Björn Haase
- Re: [Cfrg] aPAKE Analysis Hugo Krawczyk
- Re: [Cfrg] aPAKE Analysis Jonathan Hoyland
- Re: [Cfrg] aPAKE Analysis Hugo Krawczyk
- Re: [Cfrg] aPAKE Analysis Wang Guilin
- Re: [Cfrg] aPAKE Analysis Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] aPAKE Analysis Hugo Krawczyk
- Re: [Cfrg] aPAKE Analysis Hugo Krawczyk
- Re: [Cfrg] aPAKE Analysis Björn Haase
- Re: [Cfrg] aPAKE Analysis Jonathan Hoyland
- Re: [Cfrg] aPAKE Analysis Björn Haase
- Re: [Cfrg] aPAKE Analysis Jonathan Hoyland
- Re: [Cfrg] aPAKE Analysis Blumenthal, Uri - 0553 - MITLL