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

[Hugo Krawczyk <[e-mail]>]

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