Subject: Re: [Cfrg] [Crypto-panel] Fwd: I-D Action: draft-irtf-cfrg-spake2-12.txt

From: Watson Ladd <[email-masked]>
Date: Fri, 11 Sep 2020 13:41:07 -0400

I have just uploaded version -13 which contains suggested text from
Michel by way of Bjorn.

Given we have per-user M and N as an option I decided not to add
per-protocol, but if Scott thinks it's a good idea I'm happy to add
it: not sure it will be used.

On Mon, Aug 24, 2020 at 9:03 AM Björn Haase <[email-masked]> wrote:
>
> Dear Watson,
>
> If I understood correctly Manuel and Michel's proof, the reduction to the GAP version of CDH problem refers only to the "perfect-forward security" aspect of the SPAKE2 proofs.
>
> To my best knowledge, the game-based proof regarding the "only one password guess per session" feature does rely on "Discrete Logarithm Password-based Chosen-basis Computational Diffie-Hellman assumption" (DLPWBCDH) (i.e. without the "GAP").
>
> IIRC there is some small margin between the CDH and DLPWBCDH but there is no need for the GAP assumption when carrying out the proof in the game-based models, except for the forward-security aspect which to my knowledge requires the DDH oracle.
>
> For the UC proofs, OTOTH the GAP assumption appears to be mandatory, IIUC, since this proof strategy also implies forward security.
>
> I'm in close contact with Michel for the CPace draft preparation and I'll ask him what specific wording he would be recommending for your document, the next time I'll be talking to him.
>
> Yours,
>
> Björn.
>
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
>
> Senior Expert Electronics | TGREH Electronics Hardware
>
> Endress+Hauser Liquid Analysis
>
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221
> [email-masked] |  www.ehla.endress.com
>
>
>
>
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Cfrg <[email-masked]> Im Auftrag von Watson Ladd
> Gesendet: Montag, 24. August 2020 14:42
> An: Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]>
> Cc: [email-masked]; <[email-masked]> <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
> Betreff: Re: [Cfrg] [Crypto-panel] Fwd: I-D Action: draft-irtf-cfrg-spake2-12.txt
>
> On Sun, Aug 23, 2020 at 3:20 PM Scott Fluhrer (sfluhrer)
> <sfluhrer=[email-masked]> wrote:
> >
> > I looked through it (the Crypto20 crypto conference was last week, that kept me busy); it looked good, with two nits:
>
> Thank you very much for reviewing it so quickly!
>
> >
> >
> >
> > Section 3.1 states “Lets G be a group in which the computational Diffie-Hellman (CDH) problem is hard”.  Actually, if you go through the security proof, it appears that the slightly stronger “S-PCCDH assumption” is required.  While it is plausible that, for any group where the CDH assumption holds, so does the S-PCCDH assumption, however, this is not proven.
>
> So recently https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2019%2F1194.pdf&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=TwffvrezUzSnJeaPaahlF08H744LL1mxocrTksHdvo0%3D&amp;reserved=0 reduces to Gap
> Diffie-Hellman. I think I should revise that sentence of 3.1 and
> discuss in security considerations section exactly what is assumed and
> that elliptic curves in the draft are widely conjectured to satisfy
> it. Hopefully this won't confuse anyone more than necessary.
>
> > This draft still relies on a fixed (per group) M and N values; as we have argued before, having a global N and M value menas that breaking one discrete problem would mean breaking the entire system globally, and so that arguably too attractive as a target.  Assuming that the authors aren’t willing to use a Hash2Curve method to generate N, M values, I would recommend that a paragraph be added to the document outlining the situation (and perferably giving a procedure where individual protocols can select their own N, M values)
>
> Section 5: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-irtf-cfrg-spake2-11.html%23rfc.section.5&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=TSxHJGOCsecYGoYp4OwBajfg%2FXt%2F9aLbokD%2F7iKprK0%3D&amp;reserved=0
> has M and N per user, following one of the papers in the references.
> I think a per-protocol option makes sense to add, but it would be nice
> to know if it would be used.
>
>
> >
> >
> >
> > From: Scott Fluhrer (sfluhrer)
> > Sent: Monday, August 17, 2020 7:50 AM
> > To: Stanislav V. Smyshlyaev <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
> > Cc: Alexey Melnikov <[email-masked]>; [email-masked]
> > Subject: RE: [Crypto-panel] Fwd: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-12.txt
> >
> >
> >
> > I’ll take a quick look at it.
> >
> >
> >
> > From: Crypto-panel <[email-masked]> On Behalf Of Stanislav V. Smyshlyaev
> > Sent: Monday, August 17, 2020 4:40 AM
> > To: Russ Housley <[email-masked]>; [email-masked]
> > Cc: Alexey Melnikov <[email-masked]>; [email-masked]
> > Subject: Re: [Crypto-panel] Fwd: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-12.txt
> >
> >
> >
> > Dear Russ, dear Crypto Panel experts,
> >
> >
> >
> > Any volunteers for a quick review of the updated version of the SPAKE2 draft (before commencing a RGLC)?
> >
> >
> >
> > Regards,
> >
> > Stanislav
> >
> >
> >
> > On Tue, 11 Aug 2020 at 20:02, Alexey Melnikov <[email-masked]> wrote:
> >
> > On 11/08/2020 17:47, Alexey Melnikov wrote:
> >
> > Hi Russ,
> >
> > On 11/08/2020 17:43, Russ Housley wrote:
> >
> > > We recommend the following two protocols to be selected as «recommended by the CFRG for usage in IETF protocols»: one balanced PAKE - CPace, and one augmented PAKE - OPAQUE.
> >
> >
> >
> > What was the point of the selection process if we are going to publish the ones that were not selected too?
> >
> > It is needed by Kitten WG for one of Kerberos documents. The idea is to publish it with a disclaimer that it predated PAKE selection process and was not selected as one of the finalists.
> >
> > To clarify: we don't intend to publish any other PAKE candidates that weren't finalists.
> >
> > Best Regards,
> >
> > Alexey
> >
> >
> >
> > Russ
> >
> >
> >
> >
> >
> >
> >
> > On Aug 11, 2020, at 10:57 AM, Stanislav V. Smyshlyaev <[email-masked]> wrote:
> >
> >
> >
> > Dear Crypto Panel experts,
> >
> >
> >
> > Could someone please take a quick look at the updated version (taking into account the reviews made during the PAKE selection process)?
> >
> >
> >
> > Regards,
> >
> > Stanislav (on behalf of CFRG chairs)
> >
> >
> >
> > ---------- Пересылаемое сообщение ---------
> > От: Watson Ladd <[email-masked]>
> > Дата: пн, 10 авг. 2020 г. в 23:29
> > Тема: Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-12.txt
> > Кому: <[email-masked]>
> >
> >
> >
> > This fixes the comment on missing identities received during the PAKE
> > competition which was the only one I found.
> >
> > I think it's ready for RGLC.
> >
> > On Mon, Aug 10, 2020 at 4:27 PM <[email-masked]> wrote:
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the Crypto Forum RG of the IRTF.
> > >
> > >         Title           : SPAKE2, a PAKE
> > >         Authors         : Watson Ladd
> > >                           Benjamin Kaduk
> > >         Filename        : draft-irtf-cfrg-spake2-12.txt
> > >         Pages           : 16
> > >         Date            : 2020-08-10
> > >
> > > Abstract:
> > >    This document describes SPAKE2 which is a protocol for two parties
> > >    that share a password to derive a strong shared key with no risk of
> > >    disclosing the password.  This method is compatible with any group,
> > >    is computationally efficient, and SPAKE2 has a security proof.  This
> > >    document predated the CFRG PAKE competition and it was not selected.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-irtf-cfrg-spake2%2F&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=lfQZ%2Bk58AZtuJDwwoL3kp9h%2B1t6eVh%2BO4IhcPF%2BJA9k%3D&amp;reserved=0
> > >
> > > There are also htmlized versions available at:
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-cfrg-spake2-12&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=M%2B1R6InBuduuxEehA%2Fmz99McvXt8KnILIj9S2bRBifs%3D&amp;reserved=0
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-cfrg-spake2-12&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=9IrixLVgOePrXOr4FXNIgwa8x9Jgpldlq5tr55o%2FGgI%3D&amp;reserved=0
> > >
> > > A diff from the previous version is available at:
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-irtf-cfrg-spake2-12&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=TI3p%2F1EM4Un4No8%2BEY6KsExVBQyMXIlg6OzWoZFi8%2FU%3D&amp;reserved=0
> > >
> > >
> > > 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.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > https://eur03.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=JLdVl7lCQLtmHJiKclYtzm81ubwwTgRe29PJMfhIPtY%3D&amp;reserved=0
> > >
> > >
> > > _______________________________________________
> > > Cfrg mailing list
> > > [email-masked]
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691634306&amp;sdata=oteAqHxVYJtxizv9OX5GP3qfiAuWTpgeZXxZPIlj3z8%3D&amp;reserved=0
> >
> >
> >
> > --
> > "Man is born free, but everywhere he is in chains".
> > --Rousseau.
> >
> > _______________________________________________
> > Cfrg mailing list
> > [email-masked]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691634306&amp;sdata=oteAqHxVYJtxizv9OX5GP3qfiAuWTpgeZXxZPIlj3z8%3D&amp;reserved=0
> >
> > _______________________________________________
> > Crypto-panel mailing list
> > [email-masked]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcrypto-panel&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691634306&amp;sdata=w0Bf%2F8e3bInXUJ8FckOi5dK%2FRPdY879EkrXP02iaSR4%3D&amp;reserved=0
> >
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > [email-masked]
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691634306&amp;sdata=oteAqHxVYJtxizv9OX5GP3qfiAuWTpgeZXxZPIlj3z8%3D&amp;reserved=0
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691634306&amp;sdata=oteAqHxVYJtxizv9OX5GP3qfiAuWTpgeZXxZPIlj3z8%3D&amp;reserved=0

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sat, 12 Sep 2020 13:49:30 +0300

Scott, Bjoern, are you happy with the changes?

пт, 11 сент. 2020 г. в 20:41, Watson Ladd <[email-masked]>:

> > If I understood correctly Manuel and Michel's proof, the reduction to
> the GAP version of CDH problem refers only to the "perfect-forward
> security" aspect of the SPAKE2 proofs.
>
> >
>
> > To my best knowledge, the game-based proof regarding the "only one
> password guess per session" feature does rely on "Discrete Logarithm
> Password-based Chosen-basis Computational Diffie-Hellman assumption"
> (DLPWBCDH) (i.e. without the "GAP").
>
> >
>
> > IIRC there is some small margin between the CDH and DLPWBCDH but there
> is no need for the GAP assumption when carrying out the proof in the
> game-based models, except for the forward-security aspect which to my
> knowledge requires the DDH oracle.
>
> >
>
> > For the UC proofs, OTOTH the GAP assumption appears to be mandatory,
> IIUC, since this proof strategy also implies forward security.
>
> >
>
> > I'm in close contact with Michel for the CPace draft preparation and
> I'll ask him what specific wording he would be recommending for your
> document, the next time I'll be talking to him.
>
> >
>
> > Yours,
>
> >
>
> > Björn.
>
> >
>
> >
>
> >
>
> > Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
>
> > Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (
> https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Disclaimer:
>
> >
>
> > The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the material from any
> computer. This e-mail does not constitute a contract offer, a contract
> amendment, or an acceptance of a contract offer unless explicitly and
> conspicuously designated or stated as such.
>
> >
>
> >
>
> >
>
> > Cc: [email-masked]; <[email-masked]> <[email-masked]>; Russ
> Housley <[email-masked]>; [email-masked]
>
> > > I looked through it (the Crypto20 crypto conference was last week,
> that kept me busy); it looked good, with two nits:
>
> >
>
> > > Section 3.1 states “Lets G be a group in which the computational
> Diffie-Hellman (CDH) problem is hard”.  Actually, if you go through the
> security proof, it appears that the slightly stronger “S-PCCDH assumption”
> is required.  While it is plausible that, for any group where the CDH
> assumption holds, so does the S-PCCDH assumption, however, this is not
> proven.
>
> >
>
> > So recently
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2019%2F1194.pdf&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=TwffvrezUzSnJeaPaahlF08H744LL1mxocrTksHdvo0%3D&amp;reserved=0
> reduces to Gap
>
> > > This draft still relies on a fixed (per group) M and N values; as we
> have argued before, having a global N and M value menas that breaking one
> discrete problem would mean breaking the entire system globally, and so
> that arguably too attractive as a target.  Assuming that the authors aren’t
> willing to use a Hash2Curve method to generate N, M values, I would
> recommend that a paragraph be added to the document outlining the situation
> (and perferably giving a procedure where individual protocols can select
> their own N, M values)
>
> >
>
> > Section 5:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-irtf-cfrg-spake2-11.html%23rfc.section.5&amp;data=02%7C01%7Cbjoern.haase%40endress.com%7C8359743fd98a4c38077608d8482b33bd%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C1%7C637338697691624309&amp;sdata=TSxHJGOCsecYGoYp4OwBajfg%2FXt%2F9aLbokD%2F7iKprK0%3D&amp;reserved=0
>
> > > To: Stanislav V. Smyshlyaev <[email-masked]>; Russ Housley <
> [email-masked]>; [email-masked]
>
> > > > We recommend the following two protocols to be selected as
> «recommended by the CFRG for usage in IETF protocols»: one balanced PAKE -
> CPace, and one augmented PAKE - OPAQUE.
>
> > >
>
> > >
>
> > >
>
> > > It is needed by Kitten WG for one of Kerberos documents. The idea is
> to publish it with a disclaimer that it predated PAKE selection process and
> was not selected as one of the finalists.
>
> > >
>
> > > Could someone please take a quick look at the updated version (taking
> into account the reviews made during the PAKE selection process)?
>
> > >
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>

---

From: Björn Haase <[email-masked]>
Date: Sun, 20 Sep 2020 16:48:28 +0200

Hello Stanislav,

sorry for the late reply.

 >Scott, Bjoern, are you happy with the changes?

I've only shortly reviewed the change regarding the assumption set and I
think that the reader interrested in all of the intricated details will
anyway have to dig through the papers., I think that the accuracy for
the level of an RFC document to refer just to "GAP-CDH" is fine, in my
opinion, given that the references to the papers are now integrated in
the document.

Yours,

Björn.

Am 12.09.2020 um 12:49 schrieb Stanislav V. Smyshlyaev:
> пт, 11 сент. 2020 г. в 20:41, Watson Ladd <[email-masked]
> <mailto:[email-masked]>>:
>
>     On Mon, Aug 24, 2020 at 9:03 AM Björn Haase
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     >
>
>     > Dear Watson,
>
>     >
>
>     > If I understood correctly Manuel and Michel's proof, the
>     reduction to the GAP version of CDH problem refers only to the
>     "perfect-forward security" aspect of the SPAKE2 proofs.
>
>     >
>
>     > To my best knowledge, the game-based proof regarding the "only
>     one password guess per session" feature does rely on "Discrete
>     Logarithm Password-based Chosen-basis Computational Diffie-Hellman
>     assumption" (DLPWBCDH) (i.e. without the "GAP").
>
>     >
>
>     > IIRC there is some small margin between the CDH and DLPWBCDH but
>     there is no need for the GAP assumption when carrying out the
>     proof in the game-based models, except for the forward-security
>     aspect which to my knowledge requires the DDH oracle.
>
>     >
>
>     > For the UC proofs, OTOTH the GAP assumption appears to be
>     mandatory, IIUC, since this proof strategy also implies forward
>     security.
>
>     >
>
>     > I'm in close contact with Michel for the CPace draft preparation
>     and I'll ask him what specific wording he would be recommending
>     for your document, the next time I'll be talking to him.
>
>     >
>
>     > Yours,
>
>     >
>
>     > Björn.
>
>     >
>
>     >
>
>     >
>
>     > [email-masked] <mailto:[email-masked]> |
>     www.ehla.endress.com <http://www.ehla.endress.com>
>
>     >
>
>     >
>
>     >
>
>     >
>
>     >
>
>     > Dieser Informationspflicht kommen wir mit folgendem
>     Datenschutzhinweis
>     (https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>     >
>
>     >
>
>     >
>
>     >
>
>     >
>
>     > Disclaimer:
>
>     >
>
>     > The information transmitted is intended only for the person or
>     entity to which it is addressed and may contain confidential,
>     proprietary, and/or privileged material. Any review,
>     retransmission, dissemination or other use of, or taking of any
>     action in reliance upon, this information by persons or entities
>     other than the intended recipient is prohibited. If you receive
>     this in error, please contact the sender and delete the material
>     from any computer. This e-mail does not constitute a contract
>     offer, a contract amendment, or an acceptance of a contract offer
>     unless explicitly and conspicuously designated or stated as such.
>
>     >
>
>     >
>
>     >
>
>     > Von: Cfrg <[email-masked] <mailto:[email-masked]>>
>     Im Auftrag von Watson Ladd
>
>     > An: Scott Fluhrer (sfluhrer)
>     <sfluhrer=[email-masked]
>     <mailto:[email-masked]>>
>
>     > Cc: [email-masked] <mailto:[email-masked]>;
>     <[email-masked] <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>>; Russ Housley <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     > <sfluhrer=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > >
>
>     > > I looked through it (the Crypto20 crypto conference was last
>     week, that kept me busy); it looked good, with two nits:
>
>     >
>
>     > > Section 3.1 states “Lets G be a group in which the
>     computational Diffie-Hellman (CDH) problem is hard”. Actually, if
>     you go through the security proof, it appears that the slightly
>     stronger “S-PCCDH assumption” is required.  While it is plausible
>     that, for any group where the CDH assumption holds, so does the
>     S-PCCDH assumption, however, this is not proven.
>
>     >
>
>     > So recently
>     > > This draft still relies on a fixed (per group) M and N values;
>     as we have argued before, having a global N and M value menas that
>     breaking one discrete problem would mean breaking the entire
>     system globally, and so that arguably too attractive as a target. 
>     Assuming that the authors aren’t willing to use a Hash2Curve
>     method to generate N, M values, I would recommend that a paragraph
>     be added to the document outlining the situation (and perferably
>     giving a procedure where individual protocols can select their own
>     N, M values)
>
>     >
>
>     > Section 5:
>     > > To: Stanislav V. Smyshlyaev <[email-masked]
>     <mailto:[email-masked]>>; Russ Housley <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     > > Cc: Alexey Melnikov <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     > > From: Crypto-panel <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Stanislav V.
>     Smyshlyaev
>
>     > > To: Russ Housley <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     > > Cc: Alexey Melnikov <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>     > > Any volunteers for a quick review of the updated version of
>     the SPAKE2 draft (before commencing a RGLC)?
>
>     > >
>
>     > >
>
>     > >
>
>     > > Regards,
>
>     > >
>
>     > > Stanislav
>
>     > >
>
>     > >
>
>     > >
>
>     > > On Tue, 11 Aug 2020 at 20:02, Alexey Melnikov
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > >
>
>     «recommended by the CFRG for usage in IETF protocols»: one
>     balanced PAKE - CPace, and one augmented PAKE - OPAQUE.
>
>     > >
>
>     > >
>
>     > >
>
>     > > What was the point of the selection process if we are going to
>     publish the ones that were not selected too?
>
>     > >
>
>     > > It is needed by Kitten WG for one of Kerberos documents. The
>     idea is to publish it with a disclaimer that it predated PAKE
>     selection process and was not selected as one of the finalists.
>
>     > >
>
>     > > On Aug 11, 2020, at 10:57 AM, Stanislav V. Smyshlyaev
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > >
>
>     > >
>
>     > >
>
>     > > Could someone please take a quick look at the updated version
>     (taking into account the reviews made during the PAKE selection
>     process)?
>
>     > >
>
>     > >
>
>     > >
>
>     > > Regards,
>
>     > >
>
>     > > От: Watson Ladd <[email-masked]
>     <mailto:[email-masked]>>
>
>     > > Кому: <[email-masked] <mailto:[email-masked]>>
>
>     > >
>
>     > >
>
>     > >
>
>     > > On Mon, Aug 10, 2020 at 4:27 PM <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     > > >
>
>     > > >
>
>     > > > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     > > >
>
>     > > > [email-masked] <mailto:[email-masked]>
>
>     > > >
>     > > [email-masked] <mailto:[email-masked]>
>
>     > >
>     > > [email-masked] <mailto:[email-masked]>
>
>     > >
>     > > [email-masked] <mailto:[email-masked]>
>
>     > >
>     > [email-masked] <mailto:[email-masked]>
>
>     >
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 23 Sep 2020 10:49:24 +0300

Thanks a lot, Bjoern!

Scott? Are you happy with the changes?..

Regards,
Stanislav

On Mon, 21 Sep 2020 at 18:43, Björn Haase <[email-masked]> wrote:

> anyway have to dig through the papers., I think that the accuracy for the
> level of an RFC document to refer just to "GAP-CDH" is fine, in my opinion,
> given that the references to the papers are now integrated in the document.
>
> Yours,
>
> Björn.
>
>> > The information transmitted is intended only for the person or entity
>> to which it is addressed and may contain confidential, proprietary, and/or
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>