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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 6 May 2020 15:10:28 +0300

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 6 May 2020 12:05:12 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Björn Haase <[email-masked]>
Date: Thu, 14 May 2020 17:26:27 +0200

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.

Yours,

Björn.

Am 06.05.2020 um 18:05 schrieb Hugo Krawczyk:
> 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
> 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 :-)
>
> 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
> <[email-masked] <mailto: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.
>     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.
>     *
>     *
>     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
>     [email-masked] <mailto:[email-masked]>

---

From: "Björn Haase" <[email-masked]>
Date: Sat, 16 May 2020 16:17:40 +0200

Hello to all,

regarding the CPace I-D I have meanwhile received feedback from several people which have independently implemented CPace, partly in incompatible ways (e.g. using different domain-separation identifiers).

Specifically, Steve Thomas, Frank Denis and Filippo Valsorda seem to have implemented the protocol using X25519 and Ristretto255 for C, Go, Rust (and maybe Javascript?).

I would like to avoid that several incompatible implementations get out in the wild for the same group. For this reason, I would like to update the current I-D soon. Specifically there seems to be a larger interrest of having a specification for Ristretto255.

For this purpose, I have collected all feedback that I have received so far at

https://github.com/BjoernMHaase/AuCPace/issues/3

I'd appreciate feedback from CFRG regarding how to consider different curves. My original plan was to just refer to the recently updated H2C draft for the mapping operation for any curve and use the generic specification that has recently be updated regarding the hash-to-base operation.

However, when seeing that ristretto does not seem to be considered in the H2C draft and considering that ristretto255 itself seems to specify a H2C operation, one might have to deviate from the "use the generic H2C specification" plan.?

I'd appreciate your feedback here also regarding the general assessment of ristretto255 by the CFRG group. Is this something which should be considered in the balanced PAKE document to be provided by CFRG or rather not? Should ristretto255 be left out for an official CFRG document or not?

Also I'd appreciate feedback regarding whether the current CPace-01 draft could serve as a basis for a CFRG balanced PAKE document or whether one would be rather start re-writing from scratch?  From Frank Denis, I have received the feedback "The I-D is excellent, and contains everything an implementer would need.", however Yaron did have some objections regarding the general structure, IIRC.

Yours,

Björn