[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 > > > > > > > >
- [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Russ Housley
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 steve
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Stefan Santesson
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Riad S. Wahby
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 stef
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Riad S. Wahby
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 stefan marsiske
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Riad S. Wahby
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Campagna, Matthew
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 steve
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 steve
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Watson Ladd
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Eric Rescorla
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Eric Rescorla
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hugo Krawczyk
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Eric Rescorla
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Hao, Feng
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Watson Ladd
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Christopher Patton
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Christopher Patton
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Kevin Lewi
- [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13 Stanislav V. Smyshlyaev