[Cfrg] Fwd: New Version Notification for draft-krawczyk-cfrg-opaque-04.txt
Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 15 May 2020 03:20 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 DFD5F3A07EA for <cfrg@ietfa.amsl.com>; Thu, 14 May 2020 20:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 dhfpAsp2QCir for <cfrg@ietfa.amsl.com>; Thu, 14 May 2020 20:20:35 -0700 (PDT)
Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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 2D6273A080B for <cfrg@ietf.org>; Thu, 14 May 2020 20:20:34 -0700 (PDT)
Received: by mail-ej1-f47.google.com with SMTP id l21so996029eji.4 for <cfrg@ietf.org>; Thu, 14 May 2020 20:20:34 -0700 (PDT)
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=5ByHAUxUt6e8+PpM0vXVWDABWqJyfyRDRclEZKiV5/g=; b=kAPV9qzNqo12GnrC1rScLnHxMyCzFQMjp92q3YOawG5oeDbPMq4iPAyKyWgQpcpEfw vQ5h33F4Cibmn6ht+YdvNT8vYzY7Nq2Q6t9Q+ordM0GmjYG0msIONt4OFmwHjYZCIK0O msRk4P/41Q792bgIXaO7h+Lf7lpg2pvc7DrKBLI6w3bA7j51kzLLDHlNSAsd/uuzTlO2 M11MQfth4rEal8Z1eeKt5XE422lUHcBQyXOqkyTt/yIAyPTEoJI+xFCRsJpS9IfEI5Ec 62IB7wgVOMhIAWDITEHBp8X/RVta9l66OLSMcJXktcsEbQGbQIfUOjHccoPHnmEMi/BP arpA==
X-Gm-Message-State: AOAM532GuTq2Bk1JbfHidievL+eMw64dSPCqIyu9j+xRaTcL12yq6xqX 5kti3maIWH5vQ+dBxHrZI5RBsSbdib4nOYxCFLDoumVy
X-Google-Smtp-Source: ABdhPJxB79W7d4D+XKzL40dp6HB262YTUQIy82TpgH5zjCgTlqLsYw98Vj4EzsV1hHELL3pzc7cYbCZdfpdSeWyhFns=
X-Received: by 2002:a17:906:6453:: with SMTP id l19mr893496ejn.169.1589512833007; Thu, 14 May 2020 20:20:33 -0700 (PDT)
MIME-Version: 1.0
References: <158951036376.16849.15209527810376849098@ietfa.amsl.com>
In-Reply-To: <158951036376.16849.15209527810376849098@ietfa.amsl.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 14 May 2020 23:20:06 -0400
Message-ID: <CADi0yUOXo+oyQw5PHDROMcH3nn3BbyVV=GozujK-WQ9j0=ePZQ@mail.gmail.com>
To: "<cfrg@ietf.org>" <cfrg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7073e05a5a74ba1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/yIqucxIN8iY-G66_83ZD2qMCFRs>
Subject: [Cfrg] Fwd: New Version Notification for draft-krawczyk-cfrg-opaque-04.txt
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: Fri, 15 May 2020 03:20:38 -0000
I posted version 04 of the OPAQUE draft (see links in the forwarded message). Main changes from 03 are: - An expanded section on how to build the EnvU envelope. The specification is general, but for concreteness, the (random-key robust) authenticated encryption is specified using AES-CTR and HMAC. The general mode is encrypt-then-MAC with any encryption but only with MAC functions that are also collision resistant. So it makes sense to choose HMAC (with 256 or more bits of output) as the MAC. For encryption I chose AES-CTR and included an appendix with the description of such a mode. This does not have to be the final specification for EnvU but I wanted to have one concrete proposal for now. I removed any discussion on accommodating any mode other than encrypt-then-HMAC. GCM is allowed but only as GCM-then-HMAC (which would compute GHASH unnecessarily, but it may be convenient for those that want to use the GCM API). - I expanded details on the integration of specific key-exchange protocols within OPAQUE. It includes three protocols: HMQV, 3DH and SIGMA-I. The latter is a natural choice as it is the protocol to be integrated with TLS (and its 4-message variant, not presented, would support integration with IKEv2). HMQV is there as the most efficient instantiation of OPAQUE but since it has a patent I added 3DH. 3DH is the basis of SIGNAL and it is identical to HMQV on the wire, only the key derivation changes. This same specification can be extended to semi-static TLS, the Noise family, and possibly the post-quantum AKEs built on KEMs. All these cases can use, in principle, the same messages on the wire and differ in key derivation. - The OPRF definition was changed not to include the value vU=g^kU under the hash. This was there before because of some provability issues with multiplicative blinding, but in a recent paper we show this addition to the hash is not needed. At the same time, I changed the presentation to exponential blinding for the sake of simplicity (not carrying vU around). This section is essentially a placeholder as the OPRF specification will be completely "outsourced" to the voprf document and its suites (which will also determine implementation details related to specific curves which the current draft does not discuss at all). - I added a subsection on identities that are essential for the security of key-exchange protocols. I assume that OPAQUE will be adopted as a WG item and the draft will morph into a more precise, standard- and implementation-oriented document. Chris Wood has offered his much needed help for producing such document so I hope that we will produce a better version soon. There will be a parallel effort to specify the integration of OPAQUE with TLS, a work that was initiated in the past but was paused while CFRG was making a determination on PAKE protocols. Hugo ---------- Forwarded message --------- From: <internet-drafts@ietf.org> Date: Thu, May 14, 2020 at 10:39 PM Subject: New Version Notification for draft-krawczyk-cfrg-opaque-04.txt To: Hugo Krawczyk <hugokraw@gmail.com> A new version of I-D, draft-krawczyk-cfrg-opaque-04.txt has been successfully submitted by Hugo Krawczyk and posted to the IETF repository. Name: draft-krawczyk-cfrg-opaque Revision: 04 Title: The OPAQUE Asymmetric PAKE Protocol Document date: 2020-05-15 Group: Individual Submission Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-krawczyk-cfrg-opaque-04.txt Status: https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/ Htmlized: https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque Diff: https://www.ietf.org/rfcdiff?url2=draft-krawczyk-cfrg-opaque-04 Abstract: This draft describes the OPAQUE protocol, a secure asymmetric password authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. Prior aPAKE protocols did not use salt and if they did, the salt was transmitted in the clear from server to user allowing for the building of targeted pre-computed dictionaries. OPAQUE security has been proven by Jarecki et al. (Eurocrypt 2018) in a strong and universally composable formal model of aPAKE security. In addition, the protocol provides forward secrecy and the ability to hide the password from the server even during password registration. Strong security, versatility through modularity, good performance, and an array of additional features make OPAQUE a natural candidate for practical use and for adoption as a standard. To this end, this draft presents several instantiations of OPAQUE and ways of integrating OPAQUE with TLS. This draft presents a high-level description of OPAQUE highlighting its components and modular design. It also provides the basis for a specification for standardization but a detailed specification ready for implementation is beyond the current scope of this document (which may be expanded in future revisions or done separately). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
- [Cfrg] Fwd: New Version Notification for draft-kr… Hugo Krawczyk