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.
>
>
>