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

Hugo Krawczyk <hugo@ee.technion.ac.il> Wed, 06 May 2020 16:05 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 7732C3A0B7C for <cfrg@ietfa.amsl.com>; Wed, 6 May 2020 09:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 zTzzzyGn-mKs for <cfrg@ietfa.amsl.com>; Wed, 6 May 2020 09:05:43 -0700 (PDT)
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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 DE1C63A0B71 for <cfrg@irtf.org>; Wed, 6 May 2020 09:05:42 -0700 (PDT)
Received: by mail-ed1-f49.google.com with SMTP id l3so2367539edq.13 for <cfrg@irtf.org>; Wed, 06 May 2020 09:05:42 -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=LJPHwg+eUpwasLxY78r87kP3Ows9oEceLzMixeZn5s8=; b=GdrU2ywnTM70OqyaO4+654XScFZkSuMH/zrI7f/9Og6/cfnB8VLZclZLt1l6YT6tkE hEAPg35QA35G1WbAGQEjJx47u2E6r+YuxqIdumafQd/V3L0FglVcG0yCVo6VEs++iRNx 19E5X6ngjzb1+HCqCqiFDk7SmjtRSflrcb0l2dluiTUNSB2yC/+2IFTnkI9v5bVfdDsY nuDIBM3ACks+7u4m2veg3adEi3Bcn1zeR8fx+He38as2TcqQ+vEWoBc6O1dl0h52rrvv v+e3SmPBzZb0Ya+DmHVRQL7G362/9L6HlfR483v+M789dyL6ZA6rzfYyrL6vJ+uyl941 wyNA==
X-Gm-Message-State: AGi0PuaZIofdIR0iP2gI3c/9O5W0pfDDx0UPSdVMrba2UhASXnZbIRAt zHU7huuMuA2gBEAqnzVZqmQNbBx3UuqsFROCYxI=
X-Google-Smtp-Source: APiQypINzkEO2Xp7UrrIAFksMhDekZgVV2c/Y/GTOVWe05xI7DXeQ1Cfxhb7EYo5LUGbsTulCQiEKLJW5PTDuEU1kOA=
X-Received: by 2002:a05:6402:154:: with SMTP id s20mr7868453edu.224.1588781140654; Wed, 06 May 2020 09:05:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6mG-Tt+c6kLzKU8PuxcwKc9ty6LWz9tjz6kKfk=p1k_=g@mail.gmail.com>
In-Reply-To: <CAMr0u6mG-Tt+c6kLzKU8PuxcwKc9ty6LWz9tjz6kKfk=p1k_=g@mail.gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Wed, 6 May 2020 12:05:12 -0400
Message-ID: <CADi0yUMy7rK0L_hctTLV7K9MqOYkpQbXhRDfcX8+8Nm4i9wBFA@mail.gmail.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Cc: CFRG <cfrg@irtf.org>, cfrg-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083bed905a4fcef07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mXkzM7HsprNXbNTDJ35g3HhQ4sY>
Subject: Re: [Cfrg] Further actions on PAKEs: one/two documents; call for editors
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: Wed, 06 May 2020 16:05:46 -0000

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
https://tools.ietf.org/html/draft-sullivan-tls-opaque-00.

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 <smyshsv@gmail.com>
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@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>