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

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

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.
>
> Kevin
>
> On Sun, Feb 11, 2024 at 8:59 PM Kevin Lewi <[e-mail]> wrote:
>
>> (Replying to:
>> https://mailarchive.ietf.org/arch/msg/cfrg/Fxxdbe6sBae9yqTtZfwrGvtAKRQ/)
>>
>> Hi Steve,
>>
>> Appreciate the review and the feedback! Here are my thoughts:
>>
>> 1) "There should be a section mentioning that OPAQUE is doubly augmented
>> and why that's better than augmented."
>>
>> I gave this some thought and I think I understand the distinction between
>> an sdPAKE vs. aPAKE. But I am not entirely sure if we should get into this
>> level of detail in the draft, mainly because I am struggling to figure out
>> how to phrase this in a way that is generally understandable to most
>> readers without causing confusion. However, if you do feel like this would
>> be necessary to include in the draft text, can you perhaps write up a
>> suggested paragraph under a new subsection of the "Security Considerations"
>> section which covers this detail? Then we can discuss and iterate on the
>> wording. You can also open a PR on
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pulls and we can continue
>> the discussion via comments over there.
>>
>> 2) Section 10.3. "Related Protocols" should probably be removed.
>>
>> I agree, good suggestion! I went ahead and put up a PR for this change.
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443
>>
>> 3) The mentions of "offline registration" should be changed to "online
>> registration".
>>
>> Good point, this is confusing. Seems like we have a PR up (
>> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439) to address
>> this, by changing "offline registration" to simply read as "registration"
>> (no "online"). Let me know if that also sounds acceptable.
>>
>> 4) Now the good parts of OPAQUE that weren't mentioned. Stateless HSM
>> implementation.
>>
>> I agree with this as well, but similar to point #1, do you think that
>> this is something that we actually need to include explicitly in the draft
>> text? And if so, do you have a suggested change or wording that would be
>> suitable for adding to one of the sections?
>>
>> Let me know if I missed anything.
>>
>> Thanks,
>> Kevin
>>
>>
>> On Thu, Feb 1, 2024 at 12:39 AM <[e-mail]> wrote:
>>
>>> I've been meaning to do a full review and just checked the status. So
>>> this might be a little rushed. Anyway...
>>>
>>> ----
>>>
>>> "Asymmetric PAKE" is not a thing. aPAKE means "augmented PAKE" and some
>>> time ago people saw "aPAKE" and thought it meant asymmetric because of it's
>>> asymmetrical relation between the client and server. The first PAKE was a
>>> balanced PAKE and it was then augmented so that a server doesn't hold a
>>> password equivalent. There are currently four types of PAKEs: balanced,
>>> augmented, doubly augmented, and identity. Abbreviated bPAKE, aPAKE, dPAKE,
>>> iPAKE and if the non-balanced PAKE has an OPRF then it is "strong" and is
>>> prefixed with an "s". Note that bPAKE ⊂ aPAKE ⊂ dPAKE ⊂ iPAKE. For info on
>>> iPAKEs see https://eprint.iacr.org/2020/529.
>>>
>>> Doubly augmented PAKEs' best use case is WiFi: compromising a device
>>> doesn't lead to being able to act as an AP. The first description of a
>>> dPAKE: "SPAKE2 can even be doubly augmented, where Alice does the same
>>> thing, but I'm not sure if there's any application to that." -Mike Hamburg (
>>> https://moderncrypto.org/mail-archive/curves/2015/000424.html). I
>>> actually couldn't think of a reason either until around the time the WiFi
>>> Alliance picked a known to be broken bPAKE.
>>>
>>> Which brings us to OPAQUE is not an aPAKE, it's a sdPAKE. One way to
>>> think of OPAQUE, as a sdPAKE, is that it's a cert delivery protocol. Once
>>> the client has the cert they just store and use it. There should be a
>>> section mentioning that OPAQUE is doubly augmented and why that's better
>>> than augmented
>>
>>