Re: [Crypto-panel] Request for review: OPAQUE

[Kevin Lewi <[e-mail]>]

Hi Scott,

Replies inline:


>
>
>    - The draft mentions that it supports multiple AKE and OPRF
>    algorithms, and that the server may want to select between them (based on
>    hardware support).  However, the client initiates the transaction, and the
>    generation of the KE1 message would appear to require knowledge of the OPRF
>    used; how does the client know this?  Is it communicated out-of-band (say,
>    in the DNS record)?  Is there expected to be a preliminary (outside the
>    protocol) phase where the client asks the server?  Or, does the client take
>    a guess and if the server doesn’t support that, it informs the client of
>    the one it does expect (and if so, from the KE1 message, how does the
>    server know which one the client guessed)?  I couldn’t find any discussion
>    of such issue in the draft, and I don’t believe it would serve the
>    implementors right by having them try to figure this out for themselves.
>       - This question comes up because one scenario I envision for Opaque
>       is “the user has a PC (or tablet or phone) which might not be the PC he
>       registered with, and wants to log into the server using his password.  The
>       PC has no stored information about the server” – how does this work?
>
>
IMO this is outside of the scope of the protocol and the draft. In the
Protocol Overview section, under Setup, we say "Prior to both stages, the
client and server agree on a configuration that fully specifies the
cryptographic algorithm dependencies necessary to run the protocol; see
{{configurations}} for details." In the past we discussed this and decided
to leave it up to the implementers, primarily because there are many ways
this negotiation could happen in practice, and if we pick one format, it
may be suitable for some but not for others.


>
>    - The draft includes support for Ristretto, which is itself currently
>    a CFRG draft. Is it expected that Ristretto will become an RFC before this
>    does?
>
>
Yes. We also have a dependency on voprf, which itself has a dependency on
Ristretto anyways.


>
>    - At one point, the draft uses “RFCXXXX” as a protocol identifier in
>    the preamble; is that expected to be replaced by the assigned RFC number?
>    If so, I would suggest you add instructions to the RFC editors to that
>    effect.
>
>
Done! Put up a PR for this change:
https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/420


>
>    -
>    - Question about 4.1.2: if the DeriveDiffieHellmanKeyPair has a
>    nonzero (but low) failure rate, why doesn’t the Store functionality retry
>    it internally, rather than asking for the server application to perform
>    that logic?  Of course, this would need to include some sanity limit (to
>    prevent a bogus input from causing an infinite loop); IMHO, this is
>    something that the application shouldn’t be tasked with.
>
>
The failure scenario for DeriveDiffieHellmanKeyPair comes from voprf's
"DeriveKeyPair" function:
https://www.ietf.org/archive/id/draft-irtf-cfrg-voprf-21.html#section-3.2.1
which already does the retry logic that you are describing before raising
the error. Presumably it would be unnecessary for us to introduce yet
another layer of a retry loop in DeriveDiffieHellmanKeyPair, no?

Thanks for the comments!

On Tue, Sep 5, 2023 at 10:59 AM Scott Fluhrer (sfluhrer) <[e-mail]>
wrote:

> Here is my review of the latest Opaque draft:
>
>
>
> It looks pretty good; I do have a few questions and nits:
>
>
>
>    - The draft mentions that it supports multiple AKE and OPRF
>    algorithms, and that the server may want to select between them (based on
>    hardware support).  However, the client initiates the transaction, and the
>    generation of the KE1 message would appear to require knowledge of the OPRF
>    used; how does the client know this?  Is it communicated out-of-band (say,
>    in the DNS record)?  Is there expected to be a preliminary (outside the
>    protocol) phase where the client asks the server?  Or, does the client take
>    a guess and if the server doesn’t support that, it informs the client of
>    the one it does expect (and if so, from the KE1 message, how does the
>    server know which one the client guessed)?  I couldn’t find any discussion
>    of such issue in the draft, and I don’t believe it would serve the
>    implementors right by having them try to figure this out for themselves.
>       - This question comes up because one scenario I envision for Opaque
>       is “the user has a PC (or tablet or phone) which might not be the PC he
>       registered with, and wants to log into the server using his password.  The
>       PC has no stored information about the server” – how does this work?
>    - The draft includes support for Ristretto, which is itself currently
>    a CFRG draft. Is it expected that Ristretto will become an RFC before this
>    does?
>    - At one point, the draft uses “RFCXXXX” as a protocol identifier in
>    the preamble; is that expected to be replaced by the assigned RFC number?
>    If so, I would suggest you add instructions to the RFC editors to that
>    effect.
>    - Question about 4.1.2: if the DeriveDiffieHellmanKeyPair has a
>    nonzero (but low) failure rate, why doesn’t the Store functionality retry
>    it internally, rather than asking for the server application to perform
>    that logic?  Of course, this would need to include some sanity limit (to
>    prevent a bogus input from causing an infinite loop); IMHO, this is
>    something that the application shouldn’t be tasked with.
>
>
>
>
>
>