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

Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 21 May 2024 03:02 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 C540FC15109E for <cfrg@ietfa.amsl.com>; Mon, 20 May 2024 20:02:48 -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_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 u6qP-rP6Nd9N for <cfrg@ietfa.amsl.com>; Mon, 20 May 2024 20:02:44 -0700 (PDT)
Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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 B1279C14F6A3 for <cfrg@irtf.org>; Mon, 20 May 2024 20:02:44 -0700 (PDT)
Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-5231efd80f2so5351649e87.2 for <cfrg@irtf.org>; Mon, 20 May 2024 20:02:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716260563; x=1716865363; 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=57kTLPpWTokMOm2CEzhp5JbfQASMaPRArojGRBgZ/fw=; b=JuKwgGN3EQJ3bUVEDI6vB7WTRYA/okEw+brbVoC0ZKl1+9ZJuXBZ+uKrpt3a7/1jxh FBKAyI9FUaF2ngtfirS1DvRKMVtfCzD0ea8Y6NHIIN94CcWp1nJnAYdBG8Jx9LFWso1P gz+S5IEdqkoXVevHYAeHb1tA1tWX/Z+N6H4/svUNIkTbZtVWJVssOi8eutn+3JOWVFDe cHrV8d5G2IlQzZ4C0xh+wSVFLYlrX6kPxQ9TFSXy3IF17reR5ZEpQk5Yoo4aGoYOCAWh q/FBlI8KLoYn++4gborViDTNDbdPqeS7ynVHapVUSiJ+Muvh4XfEAr9ItS+Q1Wg5spQz uJlQ==
X-Gm-Message-State: AOJu0Yz7vRmDeqxFXn5ndGCURiPuhuWWWc64jED9i589sCmYq1q1KZoW eeetWDzE+W7Mbi08O9LDi0Bt1ME31wjdHWLtkW7kWJrRz6mkigx5eCisG5wAAlXB8d5y2yHKXK3 9ffkBoTldA68zVx08D9IX3jnBKrY=
X-Google-Smtp-Source: AGHT+IFPi9WuvaZVIxOAYJQ8iwP+xEDnWEASdvtMJXsEvo8LKqPadCcFBB5aKYbj3P5aZpnEicRFB6bI8YX3kZWgG9I=
X-Received: by 2002:a19:f50b:0:b0:51c:6c59:627e with SMTP id 2adb3069b0e04-52210074a34mr18236276e87.42.1716260562518; Mon, 20 May 2024 20:02:42 -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>
In-Reply-To: <GV1PR01MB8436D21464504C1007B5C22BD6E92@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 20 May 2024 23:02:11 -0400
Message-ID: <CADi0yUNbiVTe9BaoCFgDaTC06Z1LMAx6q2hJDiWydpy6xFqtRQ@mail.gmail.com>
To: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
Content-Type: multipart/alternative; boundary="0000000000002bc9c70618ee0d23"
Message-ID-Hash: VGPKI5D6TZBLMN3RU5MIKC6THKNPPUTE
X-Message-ID-Hash: VGPKI5D6TZBLMN3RU5MIKC6THKNPPUTE
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/CI-PoJ3TPw4Xro8O8MXAMao8DQI>
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>

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