[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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
Main changes from 03 are:

- An expanded section on how to build the EnvU envelope. The specification
  general, but for concreteness, the (random-key robust) authenticated
  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
  as the MAC. For encryption I chose AES-CTR and included an appendix with
  description of such a mode. This does not have to be the final
  for EnvU but I wanted to have one concrete proposal for now. I removed
  discussion on accommodating any mode other than encrypt-then-HMAC. GCM is
  allowed but only as GCM-then-HMAC (which would compute GHASH
  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
  is a natural choice as it is the protocol to be integrated with TLS (and
  4-message variant, not presented, would support integration with IKEv2).
  HMQV is there as the most  efficient instantiation of OPAQUE but since it
  a patent I added 3DH. 3DH is the basis of SIGNAL and it is identical to
  on the wire, only the key derivation changes. This same specification can
  extended to semi-static TLS, the Noise family, and possibly the
  AKEs built on KEMs. All these cases can use, in principle, the same
  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
  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
  completely "outsourced" to the voprf document and its suites (which will
  determine implementation details related to specific curves which the
  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
a more precise, standard- and implementation-oriented document. Chris Wood
offered his much needed help for producing such document so I hope that we
produce a better version soon. There will be a parallel effort to specify
integration of OPAQUE with TLS, a work that was initiated in the past but
paused while CFRG was making a determination on PAKE protocols.


---------- 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
Status:         https://datatracker.ietf.org/doc/draft-krawczyk-cfrg-opaque/
Htmlized:       https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-04

   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