[CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13

[Kevin Lewi <[e-mail]>]

Hi all,

Here is a quick summary of the feedback we've received during the RGLC for
OPAQUE along with our responses.

[e-mail]

   1.

   Renaming of “asymmetric PAKE” to “augmented PAKE” and highlighting the
   “doubly augmented” property of OPAQUE:


   -

   Addressed in https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/448


   2.

   Removing of “Related Protocols” section:


   -

   Addressed in https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443


   3.

   Fixing references of “offline registration” to read as simply
   “registration”:


   -

   Addressed in https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439


   4.

   Mentioning OPAQUE’s application to Stateless HSMs


   -

   Not explicitly including in the draft text


Feng Hao

1) The original OPAQUE protocol in the 2018 paper has the subtle issue of
revealing to a passive attacker who monitors the login session whether the
user has recently changed the password. It’s worth adding an explicit
discussion I think.

   -

   We believe the draft text explains the protection against enumeration
   attacks in sufficient detail (including its two main elements: deriving the
   OPRF key from a PRF and the use of the masking key).

2) 2-pass versus 3-pass OPAQUE

   -

   We added one more bullet point in the Notable Design Differences section
   of the draft (see https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/454)
   to clarify this


And additionally:
- In this PR (https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/455) we
added a clarification to the language around the use of the OPRF seed.
Please let us know if you are willing to express support for the draft in
its current form, or have more feedback to share. Thank you!

On Wed, Apr 24, 2024 at 11:41 PM Stanislav V. Smyshlyaev <[e-mail]>
wrote:

> Dear CFRG,
>
> We would like to conclude the RGLC in the near future.
> There have been many active discussions, so we would like to ask to let
> everyone know if there exist any remaining issues with the draft.
>
> In case you have any concerns with the current version of the draft (or if
> you want to express your support for the current version) please send a
> message to the list before May 10th.
>
> Regards,
> Stanislav (for chairs)
>
> On Wed, Apr 24, 2024 at 8:28 PM Hugo Krawczyk <[e-mail]> wrote:
>
> > Thanks Steve for the research into the terminology. I assume this does
> not
> > necessitate any change in the draft given that we already adopted your
> > suggestion for the document title and replaced 'asymmetric' with
> > 'augmented'. To avoid confusion, especially with respect to the OPAQUE
> > paper title, we are remarking on the alternative term 'asymmetric' just
> in
> > parentheses in the abstract.
> >
> > Thank you,
> >
> > Hugo
> >
> >
> > On Fri, Apr 19, 2024 at 8:25 PM <[e-mail]> wrote:
> >
> >> If aPAKE is "asymmetric PAKE" then what should we call "doubly augmented
> >> PAKEs" (https://moderncrypto.org/mail-archive/curves/2015/000424.html)
> >> and "identity PAKEs" (https://eprint.iacr.org/2020/529.pdf)?
> >>
> >> Just for completeness:
> >> Balanced: 2 parties, both have the password. (peer-to-peer)
> >> Augmented: 2 parties, only one has the password. (client-server)
> >> Doubly augmented: 2 parties, only one can have the password but not
> >> required. (client-server)
> >> Identity: N parties, only one can have the password but not required.
> >> (any-any: peer-to-peer, client-server, computer-computer)
> >>
> >> ----
> >>
> >> The first aPAKEs called it augmented:
> >> A-EKE (1993): https://www.cs.columbia.edu/~smb/papers/aeke.pdf
> >> B-SPEKE (1997): https://www.jablon.org/jab97.pdf
> >>
> >> On Wikipedia, it's only augmented (The only mentions of "asymmetric" are
> >> paper titles):
> >> https://en.wikipedia.org/wiki/Password-authenticated_key_agreement
> (Only
> >> mentions augmented since it was created in July 2005)
> >> https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol (Only
> >> mentions augmented since it was added in July 2012 and still remains
> >>
> https://en.wikipedia.org/w/index.php?title=Secure_Remote_Password_protocol&diff=500754158&oldid=491006808
> >> )
> >> https://en.wikipedia.org/wiki/Encrypted_key_exchange
> >> (Didn't search all of Wikipedia just a few and some pages about PAKEs
> >> didn't say either like J-PAKE (
> >>
> https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling
> >> ))
> >>
> >> ----
> >>
> >> https://eprint.iacr.org/search?q=%22asymmetric+pake%22 No papers
> >> pre-OPAQUE.
> >> https://eprint.iacr.org/search?q=%22asymmetric+password%22 1 paper
> >> pre-OPAQUE but is unrelated to PAKEs.
> >>
> >> https://eprint.iacr.org/search?q=%22augmented+pake%22 2 papers
> >> pre-OPAQUE (2017/961, 2013/833).
> >> https://eprint.iacr.org/search?q=%22augmented+password%22 1 paper
> >> pre-OPAQUE (2017/1196).
> >>
> >> Note if you don't put quotes on your search terms it will return papers
> >> that only mention one term. Ah Google scholar is way better. Although I
> can
> >> only access a small fraction of papers to verify. Also the problem with
> >> just looking at the numbers of results on "asymmetric pake password" vs
> >> "augmented pake password" (without quotes) is well
> >> https://eprint.iacr.org/2013/833 is returned for asymmetric because it
> >> talks about asymmetric cryptography but says augmented PAKE. Also I
> don't
> >> know if Google scholar returns papers that contain the key word only in
> the
> >> reference section, but if it does the OPAQUE paper title is skewing your
> >> results.
> >>
> >> I need to run though these papers https://eprint.iacr.org/search?q=pake
> >> and put them into piles for augmented, asymmetric, neither, and both.
> >> 2017/1111 updated from neither to asymmetric after the OPAQUE paper was
> >> published. 2017/961 updated from augmented to both after the OPAQUE
> paper
> >> was published.
> >>
> >> ... OK done.
> >>
> >> The first paper to say asymmetric PAKE is a paper where Hugo Krawczyk is
> >> one of the authors (2015/1099) and the only paper before that to say
> >> asymmetric while talking about a PAKE is 2010/055. Also way more papers
> >> contained "asymmetric" than "augmented" while not talking about PAKEs.
> >> Because asymmetric cryptography is used in PAKEs. Oh counter point,
> >> 2014/805 loves the word augmented but didn't say augmented in reference
> to
> >> PAKEs (it also mentions asymmetric but not in reference to PAKEs. So
> it's
> >> in the neither pile).
> >>
> >> Papers after OPAQUE (2018/163):
> >> 16 asymmetric (2024/374, 2024/324, 2024/234, 2023/1513, 2023/1457,
> >> 2023/1434, 2023/1415, 2023/295, 2023/170, 2022/1607, 2021/824,
> 2020/1509,
> >> 2020/1043, 2020/987, 2020/313, 2020/060)
> >> 6 augmented (2024/307, 2023/324, 2021/1492, 2021/1357, 2021/839,
> 2021/696)
> >> 9 both (2023/768, 2023/454, 2021/553, 2020/529, 2020/320, 2019/1064,
> >> 2019/647, 2019/199, 2018/286)
> >> 20 neither (2024/308, 2024/012, 2023/1827, 2023/1368, 2023/1334,
> >> 2023/1243, 2023/1145, 2023/470, 2023/041, 2022/1719, 2022/770, 2021/114,
> >> 2021/026, 2020/848, 2020/361, 2020/140, 2019/1194, 2019/383, 2019/032,
> >> 2018/886)
> >>
> >> Papers where Hugo Krawczyk is an author:
> >> 5 asymmetric (2021/873, 2021/273, 2018/163, 2018/033, 2015/1099)
> >> 4 neither (2018/695, 2017/363, 2016/144, 2014/650)
> >>
> >> Papers before OPAQUE (2018/163):
> >> 3 asymmetric (2017/358*, 2016/233, 2010/055*)
> >> 7 augmented (2017/1196, 2017/961 (updated to both), 2015/1237, 2013/833,
> >> 2012/021, 2010/334, 2010/190)
> >> 2 both (2016/520, 2016/442)
> >> 46 neither (2017/1192, 2017/1111 (updated to asymmetric), 2017/1045,
> >> 2017/838, 2017/562, 2017/559, 2017/470, 2017/360, 2017/141, 2016/552,
> >> 2016/379, 2016/258, 2015/606, 2015/559, 2015/455, 2015/188, 2015/080,
> >> 2014/805, 2014/609, 2014/585, 2014/350, 2014/247, 2014/242, 2014/125,
> >> 2014/017, 2013/821, 2013/666, 2013/588, 2013/341, 2013/127, 2013/034,
> >> 2012/027, 2011/599, 2011/527, 2010/561, 2010/149, 2010/147, 2009/468,
> >> 2009/430, 2008/537, 2007/469, 2007/342, 2007/326, 2006/476, 2006/364,
> >> 2006/214)
> >>
> >> * Asymmetric is mentioned but not that it's an asymmetric PAKE.
> >> 2010/055: "The second PAKE protocol is a simple variant of the first,
> but
> >> provides security against server compromise: the protocol is an
> asymmetric
> >> protocol run between a client, who knows the password, and a server, who
> >> only stores a function of the password; if the server is compromised,
> it is
> >> still hard to recover the password."
> >> 2017/358: "In the following, in asymmetric protocols the sender is going
> >> to be called S while the receiver will be noted R. For symmetrical ones
> >> like PAKE, we will rather use P_i and P_j."
> >>
> >>
> >> > On 04/19/2024 11:10 AM CDT Hugo Krawczyk <[e-mail]> wrote:
> >> >
> >> >
> >> > Hi Steve,
> >> >
> >> > Both terms, asymmetric and augmented, have been used for client-server
> >> PAKE in the literature. In particular, searches in google scholar and on
> >> IACR eprint return more articles that use asymmetric than those using
> >> augmented (so it is not the OPAQUE paper that popularized the term).
> Given
> >> the choice, we preferred to use asymmetric in the title of the internet
> >> draft for consistency with the paper so people are not confused thinking
> >> this is a different type of protocol. However, to accommodate your
> request
> >> we changed the title to use "augmented" but left the clarification that
> >> this is also known as "asymmetric" already in the abstract to try to
> avoid
> >> confusion.
> >> >
> >> > While I can see your point about asymmetric not being a great name, I
> >> have to say that the vanilla "augmented" is not much better. It should
> have
> >> been called something like "client-server PAKE" but we have a legacy
> issue
> >> with terminology.
> >> >
> >> > Thank you again for your comments!
> >> >
> >> > Hugo
> >> >
> >> >
> >> > On Wed, Apr 17, 2024 at 11:49 AM <[e-mail]> wrote:
> >> > > Well my commit was basically undone because there aren't papers that
> >> state OPAQUE is in fact a doubly augmented PAKE. Also I think the OPAQUE
> >> paper might of popularized the wrong name of "asymmetric PAKE". Maybe
> the
> >> RFC should correct that mistake. I'd suggest removing the two "(or
> >> asymmetric)". If this was my RFC, I would add a section to explicitly
> state
> >> "asymmetric PAKE" is the wrong name because doubly augmented and
> identity
> >> PAKEs exist and they are both "asymmetric" in that both parties in the
> >> exchange are different. Also that all PAKEs use asymmetric cryptography
> and
> >> we shouldn't use names in cryptography that have well known meanings to
> >> mean other things. But I'm fine with at least not perpetuating
> "asymmetric
> >> PAKE".
> >> > >
> >> > >
> >> > >  > On 04/11/2024 6:14 PM CDT Kevin Lewi <[e-mail]>
> >> wrote:
> >> > >  >
> >> > >  >
> >> > >  > @[e-mail]: Just wanted to check one last time if you had
> a
> >> chance to review our response. We have updated the latest version of the
> >> draft (draft-irtf-cfrg-opaque-14), which we believe addresses your
> >> feedback. See also the github PR which has some additional discussion:
> >> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/448
> >> > >  >
> >> > >  > If you could let us know if the changes address your concerns,
> >> that would be great, as it would unblock the process forward.
> >> > >  >
> >> > >  > Thanks!
> >> > >  > Kevin
> >> > >  >
> >> > >  >
> >> > >  > On Mon, Mar 25, 2024 at 4:55 AM "Stanislav V. Smyshlyaev" <
> >> [e-mail]> <[e-mail]> wrote:
> >> > >  > > Dear CFRG,
> >> > >  > >
> >> > >  > > The authors have updated the draft.
> >> > >  > > Please feel free to express whether the changes address your
> >> concerns.
> >> > >  > >
> >> > >  > > Regards,
> >> > >  > > Stanislav (for chairs)
> >> > >  > >
> >> > >  > >
> >> > >  > > On Tue, Mar 5, 2024 at 9:37 AM Kevin Lewi <
> [e-mail]>
> >> wrote:
> >> > >  > > > Hi Steve!
> >> > >  > > >
> >> > >  > > > Just wanted to check in and see if you had a chance to review
> >> my response to your feedback above. Let me know if there is anything
> else
> >> that you would like to see addressed explicitly, or if we are good to go