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

[Kevin Lewi <[e-mail]>]

@[e-mail] <[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.
>>
>> 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
>>>
>>>