Re: [Cfrg] Further actions on PAKEs: one/two documents; call for editors

Björn Haase <> Thu, 14 May 2020 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3007C3A0B71 for <>; Thu, 14 May 2020 08:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yAGjgiY5kTqu for <>; Thu, 14 May 2020 08:26:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A6A23A0B45 for <>; Thu, 14 May 2020 08:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1589469985; bh=E3lkVZUHK+oDoZjDuVCMQhq6nBG6Zi2B5uduvTfOfQE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=gg+Fz3fNUO87Rzm5idvPTlq1gHpHY0LQLxtrOcNEv5AoLTWsE9M+QnQyzd8Hg8z0C eMZvfajNW98/7uj0z+ubUhe0nfTserkkLbQtmRc959f9afaSGtavX8gbBxnB5Yqswa OEPqF10GObbGEI/b7L6nRtn7bU1Qk0apAQ/k5sb8=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (mrweb101 []) with ESMTPSA (Nemesis) id 0MOzwh-1jU2xa1lMF-006Me3 for <>; Thu, 14 May 2020 17:26:25 +0200
References: <> <>
From: Björn Haase <>
Message-ID: <>
Date: Thu, 14 May 2020 17:26:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------0FED2812F6F47627CA6F9883"
X-Provags-ID: V03:K1:t23wqOgfrho9Hnvb19BEPfL+xrb7sNRMv5zFoJFzQEPS5JLnff9 r4hnjH8IiHhTwtoNEYYFUycdm00Mr9d5TJ52NGlncVrhE/STMyfuk02P8FOYwTDfP0k1Eka 94nxDwSwIN00WZR1P/dsUhkruGdzdXzbHaV7fZZssc+Ce82w+WlqWWNfAMPacESbFyFl0R7 yj0eAEjEj/wv8dRCnUUJw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vNYwN+eyl24=:5p8H/jUD7eSij2zW5JCLTn 30MqeinH7IzlBO2qKgo2aNmsdyC1okMogzio++cW+iPlLOOj3a+vRoe/vlQ3CBo+T/GNg4iUq +k4iPIoLqlwx9nTtmBs6UBsfCEc4sPCJ/K9b9AAan0s4W+XDCrgMZcdpcxdK1dps4cnit8WUV i4wlymBKpjK/iN+DaxLbrigh7NkQGPvz5fUunW7GvflpqKHsBs6zsmMu5jSruTMCLxTvHPnjI whIA716ITa5oK34kg3gyqGrKoSIJ4LZkB0lSQHTzd/9qaXCgnoMGTzlY6DN14wXs3UbCbLD67 oVuDrwrmt+I85xboUyOk0njwDC/QxUAVzrBYgDgH8RKBfUSXMzEpL0Ah1p6M2HNBt7w3wg+zw rVyZpHjOjCQTMDOgF8XSTaqfRAAEkLe7QEHh1zNiq/APqd/aRVoom5zz+HAyhmK2WwF+Ki9SB KvEBgPT082z0JOQFZo0/FgGKxZlJKKZH2NdHcbcp4gSdu4uWi0NQQsvzMUSHMjYdT6sull16V aMhQC/uUrqMnoYbqCMl/CWzpYpfMwsS/5AeMoj1i+YkhSo4yeXoWAOc2rifGEmVtpveOixmw0 zk7JUsKWIjlSgFFLn/DuA8fb4dkbHCfL7pnnvPvc7CI3w6rwBZEg9rlJITL2uchhSNEY4gIGR NK8hzIiXUczPVDkxl95U3Ko2ITnojKcURULEWsDJJKOPdZ4jHsMmZDFNevhJEtC86dxYe/m5j 6xzXxGnW0aHGExrEwumBaBlYMZTgPRypi7jeIh4e8f5O4FTLAV/yNUTJj2sKYgTDxt4U59teA Vtp5fi8akWwXcQiLXy09m7LM/7r9ay4RyBWnasnGm6R7+8vT63pvsk9TXCn/mJnwRb6fqaw12 FgQYdIK8NW+wvioJTAf5HA1aZ/sf8V36Kip4Q9JJIZgWX+tqIJWe9cv8C2kEYr2Q1Xgg/8JoS gBSJTP2o8ce89/kaY4xcYmBprYUwngtq1nS6f+LtZqSSbeAtgMvVNJH14KE6+o7fC5r3dt7IN fFc1bREh4SwmVYfPyiFgweKrbthveHfpHx0k1muEKvOXufbwq/xj5uKKAOTd2DXnF+F4Xr2rb Yf5YPiSZSNnx9T5tvLtKb9ht1nswENFCvSJc+6EV8dyaJ6AOI8xyGUHpm0ZtSSeKDrSzVVErc R3AwHXbXnqsaQruYBp7+P8/+evssVdHLSoIXWyyeKX/Zr/UXWW9q4XGNGBPpF6RM2ufyL+hUe mOMbnXq7e4LnoUBCA
Archived-At: <>
Subject: Re: [Cfrg] Further actions on PAKEs: one/two documents; call for editors
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 May 2020 15:26:31 -0000

Hi to all,

I agree with Hugo. We should be having two separate RFC. Possibly, we
could still try to closely match the structure of the writeups and maybe
we could also share some of the text.

In my opinion, we might also consider the remarks of Ran Canetti on this
list regarding the APIs. In my opinion, it would be worthwile to
explicitly consider the session id complexity in both RFC, as doing so
would facilitate integrating the two protocols into larger constructions.

I would be willing to contribute signicantly to the RFC, but I think
that there would best be some native speaker in the team.



Am 06.05.2020 um 18:05 schrieb Hugo Krawczyk:
> I strongly support Option 2. These protocols are complex enough that
> putting them together will make a monster RFC.. Even more
> significantly, the application settings are very different as are the
> properties of these functionalities. This being said, there can be a
> very high level document, for example expanding  RFC 8125, covering
> general principles for each of these settings and highlighting the
> important differences between these cases.
> I am working on expanding the OPAQUE internet draft (which I let
> expire, irresponsibly...) to include a more detailed specification.
> This is not intended to provide exact details at the level of bits on
> the wire but as a basis for defining these details. It will also serve
> as a basis to decide on what specific mechanisms to use in a default
> specification. A separate specification defining the use of OPAQUE
> with TLS 1.3 will be needed as initially drafted in
> I want to take this belated opportunity to thank the CFRG group, the
> chairs, and all the truly  dedicated reviewers for an amazing
> selection process. This would have been as remarkable even if OPAQUE
> would have not been chosen, but it is even more wonderful this way :-)
> And while at it, I want to thank, over the ether, my colleagues, Stas
> Jarecki and Jiayu Xu , co-authors of OPAQUE, for their amazing work at
> nailing down the many details of the UC proofs at the basis of the
> OPAQUE analysis. It has been an amazingly difficult work.  THANKS!
> Hugo
> On Wed, May 6, 2020 at 8:13 AM Stanislav V. Smyshlyaev
> < <>> wrote:
>     Dear CFRG,
>     This is a reminder that (as we have said at the recent CFRG
>     virtual interim) we are seeking for the opinions (and volunteers!)
>     regarding the futher steps after the end of the PAKE selection
>     process.
>     We asked the following two questions about our further actions
>     about the PAKE documents.
>     *1) Do we need one or two documents?*
>     Option 1: "Recommendations for password-based authenticated key
>     establishment in IETF protocols" with both CPace and OPAQUE.
>     Option 2: "Recommendations for balanced password-based
>     authenticated key establishment in IETF protocols" with CPace and
>     "Recommendations for augmented password-based authenticated key
>     establishment in IETF protocols" with OPAQUE.
>     *2) Call for editors, authors*
>     *
>     *
>     Regarding the number of documents: during the meeting, a certain
>     amount of support for Option 2 (two documents) was expressed (see
>     the minutes).
>     Please express your opinion here in the list (especially if you
>     are in favor of Option 1), if you have something to say.
>     *
>     *
>     And we really need editor(s) for this/these document(s) - please
>     let us know if you are happy to help!
>     Take care.
>     Best regards,
>     CFRG Chairs
>     _______________________________________________
>     Cfrg mailing list
> <>
> _______________________________________________
> Cfrg mailing list