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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear CFRG,

We’ve got enough support to proceed with this document; RGLC successful.

Regards,
Stanislav (for chairs)

On Wed, May 22, 2024 at 10:40 AM Stanislav V. Smyshlyaev <[e-mail]>
wrote:

> Dear CFRG,
>
> Taking the discussion on the mailing list into account (thanks a lot for
> the summary, Kevin!), please express your position on whether the draft
> should be published in the current form.
>
> We hope to conclude this RGLC before the end of May.
>
> Best regards,
> Stanislav (for chairs)
>
> On Wed, May 22, 2024 at 10:21 AM Kevin Lewi <[e-mail]> wrote:
>
>> 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
>>
>> _______________________________________________
>> CFRG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>