Consider dropping external mode

[chris-wood]

In #250, the rationale of external mode was called into question. Here's a list of the tradeoffs currently identified.

Pros:

• Allows external key generation e.g. for compliance reasons // is this an actual use case we care about?
• Punts deterministic key generation specification to application
• Faster private key recovery (XOR-based decryption instead of hash-to-scalar)

Cons:

• Larger API surface (possibility for misuse or abuse, harder to test, etc)
• Higher bandwidth for RegistrationRecords (more data encrypted)
• Allows for the possibility of applications to re-use private keys across protocols
• Possibly requires domain separation across modes (not currently in the spec, but might be a consideration)

It would seem that removing external mode is best. The added complexity does not seem to be justified by the expected use case.

[hugokraw]

I have one consideration that you should probably ignore but it is very useful when writing about OPAQUE in general (it is not a completely stupid consideration because being able to convey the idea behind the protocol in a simple way is a good property of a protocol). It is very easy and appealing to describe the protocol as choosing keys for the particular AKE and inserting them (user's private key and server's public key) in an "envelope protect with the password". It is more intuitive and compact than sending the server's public in an authenticated envelope and deriving the user's key from the output of the OPRF computed on the password. Or maybe it is just how it seats in my mind. As said, feel free to ignore...

[hugokraw]

PS: Maybe it is not so much about the easiness to explain but about the "elegance" of the design/description (where elegance is a highly subjective notion)

[bytemare]

I agree, it is indeed elegant, and also very smart as it is very simple. This and the usefulness of this mechanism is undoubted, even in the light of an alternative mode with quasi opposite pros and cons.

May I suggest a slightly different definition of OPAQUE (vs. how we currently describe it): Let OPAQUE be a compilation of any OPRF -> Key Recovery Mechanism -> AKE.

Technically, saying that OPAQUE = OPRF + AKE is not completely true, as the OPRF output is not directly used in the AKE. The key to make them work together is that proxy, that transforms the OPRF output into an AKE input. This more formal definition allows different implementations with their own pros/cons.

Just like setting for 3DH in this specification, setting for the internal mode here doesn't ditch other key recovery mechanisms to be defined in other, future, specifications, if desired.

From a more practical point of view, I believe that users of OPAQUE (i.e. developers that will integrate it into their product, services, etc.) will probably look for a more hassle free approach and might be willing to accept that new keys are used (key rotation vs. the need to import old keys). Another argument is: if the service provider already has the private key of their user(s), it undermines the very point of the PAKE (the secret never leaves the client). If the client already has that secret private key then they might not even need a PAKE (the client only knows a password), and would just use the AKE directly.

[bytemare]

In other words: upgrading an existing system to OPAQUE seems to make sense only if it's password-based and there are no existing keys. OPAQUE is a system to authenticate through the recovery of asymmetric keys a user doesn't have, using only a password the user has. If users already have their keys then they don't need to recover them, and thus don't need OPAQUE.

Any thoughts? Please let me know if I'm missing something :)

[hugokraw]

I agree with Daniel's comment, in particular that OPAQUE is not just OPRF+AKE but has the key recovery (now modeled through the envelope), and the latter can have different instantiations. The OPRF+AKE is used as a more intuitive description but definitely inaccurate.

If users already have their keys then they don't need to recover them, and thus don't need OPAQUE.

This is true although I can see a "hybrid" situation where the user has a private key stored in one device but wants to be able to login from a different, less secure one in which the key is not stored.

[chris-wood]

Dropped, but noted as a future extension point in the appendix as part of #255.