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

[[e-mail]]

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.
> > > 
> > > 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