[CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13

Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 21 May 2024 13:21 UTC

Return-Path: <hugokraw@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 D4D38C14F5ED for <cfrg@ietfa.amsl.com>; Tue, 21 May 2024 06:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM53zFFH7mqU for <cfrg@ietfa.amsl.com>; Tue, 21 May 2024 06:21:27 -0700 (PDT)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F65C14F713 for <cfrg@irtf.org>; Tue, 21 May 2024 06:21:26 -0700 (PDT)
Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-51f99f9e0faso6424577e87.2 for <cfrg@irtf.org>; Tue, 21 May 2024 06:21:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716297685; x=1716902485; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tS6SX2aTQWwmb4yRZEFqoMNfpib4RIHkBKezzgyatcI=; b=ZAwUII83B2mFENCTiRGgCaFberK078FHESJXyk1LE0a1qbQy/kJSEdhrQFXuxTQdLL PwSH9e63fuhCl7mkn1DkVtokb+PNHq72dS0KscC86vBA/sBBjHY/8JgtYZD1s7oZ98r2 liliacDqoplSvBh6KwNCldzVufsqMc1AFxWQxRUjeDd4tYPOdppV4QNRyPEb4lmEjkpv D/Le5qAW3/66sVC2O0bCG6jZnIU/221T0oJGUT/55BntKBzsun/SC5qVeeuW/AEp49La BziQnvdAmZ/6mmwKB5X2qbx3C74e+08huv/O9ghChEsRFNZi2ae2m0/c85Esp3Bw9Fe6 XYwQ==
X-Gm-Message-State: AOJu0YwcCwXlI8HDzPHzOVaM7+uaE6wbhn78j1URELu6aJYgT5aD260D eG/mwa+K79wYwqtq/u3j6bPSyyarzATia0PJfOqCZnoEQYy5GPzupGLLyeNYHw2/Hw23kMi1GQO acgPy66ccPFcv7Sglu2cWDD26DAg=
X-Google-Smtp-Source: AGHT+IEoBla27sGVl6yPUxokemCOytUYuI2lrXyKig/7HKDzbO2EUwOEyuAh9vQuk2WgcEzqi18T3GZ5OUC0emIDakY=
X-Received: by 2002:ac2:5603:0:b0:51a:f2eb:b4c9 with SMTP id 2adb3069b0e04-5220ff71dcamr20340777e87.1.1716297684635; Tue, 21 May 2024 06:21:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kOrbwdHEDmmGsVYzqjsEbzBCCtGL39jckNbSWsEumOQg@mail.gmail.com> <994001115.165708.1706765982169@email.ionos.com> <CACitvs8zzoQVY4uo1zOtoBWrSVOLfzGFBCsMnevxnCMXg-CJGw@mail.gmail.com> <CACitvs_kEOgBC0eZNbHZ1EBy6v7kqL2-99-A1kRD_QqTaTuQKw@mail.gmail.com> <CAMr0u6khy2oo6GpxYYWq803NPYvKHLk4=9Lf7Z5ddNVu8KbiZw@mail.gmail.com> <CACitvs-_iZ145ok1A8peN642Z2DmA=Pd1T2cJwrFnQo_PZxWqw@mail.gmail.com> <4277693.8349904.1713368966703@email.ionos.com> <CADi0yUPxQsktpso7htB5+6M+ZJRyhax+QiUBNJQa3RG5GwLfCw@mail.gmail.com> <1916772043.8833957.1713572703792@email.ionos.com> <CADi0yUPJP+PrLYxw1iCay3VFLYDqktja_51QLdW3YiKC9RW=Uw@mail.gmail.com> <CAMr0u6kypySZrDx5zMz9Y7S4U5-Z16vYSuwKvkOV89tgAh4C=w@mail.gmail.com> <GV1PR01MB8436DA9FC923665CE88FF637D61B2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUOoKRFxO85cYygX7V3jxL6kZE8hkW6S91eLa2fr_pgQ4g@mail.gmail.com> <GV1PR01MB8436A8B3E01489A85372BAAAD6192@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUP9RuR9c_jC-hDezOKz4TqqRurCPqFd18yBriZEVs1gEw@mail.gmail.com> <GV1PR01MB8436155CDCD501FD3D1C2137D6ED2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUMO+HMNNa5G4OX5O-3YRp77Y7Gdq2-ekQSuF4KnKia8=g@mail.gmail.com> <GV1PR01MB8436D21464504C1007B5C22BD6E92@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUNbiVTe9BaoCFgDaTC06Z1LMAx6q2hJDiWydpy6xFqtRQ@mail.gmail.com> <GV1PR01MB8436B6B6B75DEBC9F1FB30A9D6EA2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
In-Reply-To: <GV1PR01MB8436B6B6B75DEBC9F1FB30A9D6EA2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Tue, 21 May 2024 09:21:12 -0400
Message-ID: <CADi0yUNCkk8Y5dQJH6DjR33cP7KXXrQsmHfA0UDRxjGuoXCaLA@mail.gmail.com>
To: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
Content-Type: multipart/alternative; boundary="000000000000d257120618f6b131"
Message-ID-Hash: CCIPO5EID2FJWBQ5KBDOIDLQOGJMRHVK
X-Message-ID-Hash: CCIPO5EID2FJWBQ5KBDOIDLQOGJMRHVK
X-MailFrom: hugokraw@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IRTF CFRG <cfrg@irtf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/weo1ZpLIUN3XSA8TT-qj661Z6bc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

Yes.

On Tue, May 21, 2024, 04:01 Hao, Feng <Feng.Hao@warwick.ac.uk> wrote:

>
>
> Does OPAQUE send any key confirmation string in the second message?
>
>
>
> *From:* Hugo Krawczyk <hugo@ee.technion.ac.il>
> *Sent:* 21 May 2024 04:02
> *To:* Hao, Feng <Feng.Hao@warwick.ac.uk>
> *Cc:* IRTF CFRG <cfrg@irtf.org>
> *Subject:* Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
>
>
>
> Sorry Feng. You are wrong about the need for a 4th message in OPAQUE. Full
> forward secrecy (against passive and active attackers) is provided by the
> 3-message protocol as documented in the paper's full version and in this
> draft. The undetectable online attack you refer to in your paper has
> nothing to do with forward secrecy or the need of a 4th message in OPAQUE.
>
>
>
>
>
> On Mon, May 20, 2024 at 4:16 AM Hao, Feng <Feng.Hao@warwick.ac.uk> wrote:
>
> Hi Hugo,
>
>
>
> The cases of achieving forward security in TLS 1.3 and OPAQUE are
> different. Please allow me to elaborate.
>
>
>
> You introduced the weak/strong definitions of forward security in your
> 2005 HMQV paper. For a two-message AKE scheme with weak forward security,
> strong forward security can be obtained by sending a third message (to
> complete mutual authentication with explicit key confirmation). By “full
> forward security” in the updated OPAQUE paper on IACR e-print, I believe
> you refer to the strong notion since the paper mentions “against active
> attacks”.
>
>
>
> TLS 1.3 provides weak forward security in 1-RTT and requires 3 messages to
> achieve strong forward security. The OPAQUE paper follows the same.
>
>
>
> However, in TLS 1.3, the server holds a strong secret. But in augmented
> PAKE, the server holds a weak secret. This difference is crucial.
>
>
>
> As a result, the 3-message OPAQUE scheme with strong forward security is
> insecure as it’s vulnerable to an undetectable online dictionary attack. To
> prevent this attack, OPAQUE needs to be revised to require 3 messages to
> provide weak forward security, and 4 messages to achieve strong forward
> security.
>
>
>
> Therefore, the change from 2-message OPAQUE to 3-message OPAQUE has
> nothing to do with forward security (weak or strong). This revision in the
> protocol spec is necessary to prevent the undetectable online dictionary
> attack (which is a known attack in the PAKE literature but seems not
> covered in the original formal model and analysis in the 2018 OPAQUE
> paper). This attack doesn’t apply to TLS 1.3 because the TLS server holds a
> strong key (as opposed to a weak one).
>
>
>
> PS. We explained the undetectable online dictionary attack in our FC’24
> paper (https://eprint.iacr.org/2023/768.pdf) To the best of my
> knowledge, this attack was not discussed during the PAKE review of OPAQUE.
>
>
>
> Regards,
>
> Feng
>
>
>
> *From:* Hugo Krawczyk <hugo@ee.technion.ac.il>
> *Sent:* 17 May 2024 04:16
> *To:* Hao, Feng <Feng.Hao@warwick.ac.uk>
> *Cc:* IRTF CFRG <cfrg@irtf.org>
> *Subject:* Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
>
>
>
> The common definition of forward security, and the one followed in the
> internet draft (and paper), is that session keys remain secure (after being
> deleted) even upon the compromise of long-term key material in the future.
> In the case of aPAKEs, forward secrecy applies to the password, namely, a
> future leakage of the password does not compromise past session keys. This
> is achieved by OPAQUE in 3 messages (similar to the way that TLS 1.3
> achieves forward security in 3 messages).
>
>
>
> Hugo
>
>
>
> On Thu, May 16, 2024 at 3:49 AM Hao, Feng <Feng.Hao@warwick.ac.uk> wrote:
>
> Hi Hugo,
>
>
>
> Ø  As for the 3-message issue, to address your concern, we intend to add
> the following sentence to the noticeable differences (with OPAQUE paper)
> section:
>
>
>
> Ø  - The AKE describes a 3-message protocol where the third message
> includes client authentication material that the server is required to
> verify. This change (from the original 2-message protocol) was made to
> provide explicit client authentication and full forward security. The
> 3-message protocol is analyzed in the full version of [JKX18].
>
>
>
> Sorry for my delayed response on this. If you want full forward security
> in the strong sense (with explicit mutual key confirmation), you will need
> 4 messages for OPAQUE, not 3. You can’t do explicit key confirmation in the
> 2nd pass. So the client sends its explicit key confirmation in the 3rd
> pass, and the server can only send its explicit key confirmation in the 4
> th pass. That takes 4 passes in total. As explained earlier, the reason
> that we may call OPAQUE a 3-pass scheme is entirely because 3 passes are
> the minimum required to finish client-to-server authentication for an
> augmented PAKE in a client-server setting and that the client needs to be
> authenticated first. At the end of the 3rd pass, the authentication from
> the server to the client is still implicit. I would suggest you remove the
> “and full forward security”. The claim of full forward security for the
> 3-message OPAQUE in the full version of the paper may need to be updated as
> well.
>
>
>
> Regards,
>
> Feng
>
>
>
>
>
>
>
>