Specify harden parameters

[chris-wood]

Clients need a way to recover credential information during registration. So we should either (a) fix some Harden parameters, or (b) have servers send these during the registration and authentication flows.

@kevinlewi, what do you think?

[kevinlewi]

Can you clarify what you mean by (a)? If you mean to provide concrete settings, I think we may want to avoid that since these numbers can become out of date, and are application-dependent. For (b), I think we should avoid this as well, unless we start also deciding to send information about group representation / hash functions during these flows. Also, there is no way for the server to enforce that the client follows the harden parameters, and so these are at best recommendations.

My approach would be to allow for parameterizing the protocol based on harden parameters. So in the same way that we can have OPAQUE with Ristretto points versus Edwards, or OPAQUE with SHA3 versus Blake3, the choice of a hardened hash function should just be another parameter.

[chris-wood]

If you mean to provide concrete settings, I think we may want to avoid that since these numbers can become out of date, and are application-dependent.

Yeah, that's what I mean, and that's the risk.

My approach would be to allow for parameterizing the protocol based on harden parameters. So in the same way that we can have OPAQUE with Ristretto points versus Edwards, or OPAQUE with SHA3 versus Blake3, the choice of a hardened hash function should just be another parameter.

I think there's generally too much flexibility in what's currently in the document. We have ciphersuites, configurations, optional parameters, etc. All of this runs the risk of making implementations challenging to get right. I would be in favor of something a bit more rigid. Could you please draft a PR to take care of this with your proposal? (This would also ideally address #58.)

[kevinlewi]

I might have misinterpreted, but I was not suggesting to modify the current proposal in any way, except to suggest that when producing test vectors, we have a set which instantiates Harden with a specific function.

So my proposal is to keep everything in the draft the same, and when presenting test vectors, we provide annotated options such as:

• OPAQUE-X25519-3DH-SHA256-Scrypt10k,
• OPAQUE-Ristretto255-SigmaI-Blake3-Argon2i100k,
• etc.

This means that we will be supporting the increased flexibility that you may be against.

Btw, while we are on the topic, the flexible parameters I am currently tracking are:

• Group representation
• Keypair format
• AKE protocol
• Hash function
• Harden function

(Also represented in code here)

Let me know if you think I am missing any others...

[chris-wood]

Those match my understanding, yeah. Do we really need this sort of flexibility? I'm not sure!

Though, hmm... on reflection, why are the parameters of Harden something the configuration (server?) ought to specify at all?

[kevinlewi]

Agreed, I don't think the specification needs to specify the parameters of Harden, but an implementation may want to provide options for configuring them.

[kevinlewi]

After some offline discussion, we have settled on the following as the main point of discussion:

Let's suppose a client registers their password using a particular hardening function. How should the client on login know what parameters for the hardening function to use? Two potential options: 1) This shouldn't be part of the OPAQUE protocol, and it should be the responsibility of the wrapping protocol to ensure that the login surface's hardening parameters match those of registration, or to optionally store an annotation at registration time to help inform what parameters to use for login. 2) This should be incorporated into OPAQUE, potentially through an extra client-specified field that can be stored alongside the password file.

If we go with Option 2, there are more follow-up questions, such as whether or not this field should be free-form, if it should be authenticated, etc.

cc: @chris-wood

[hugokraw]

If the hardening parameters are transmitted from server to client, it would be better to authenticate them, or otherwise a cheating server can either apply a DoS attack on the client by sending extremely large parameters or help in a dictionary attack with small parameters (the latter would only apply to an online attack posing as the server).

[huitseeker]

I vote for option 1: This shouldn't be part of the OPAQUE protocol. While it's one of the strengths of the abstract protocol to be generic, in practice deployments will be content with one particular suite of sub-protocols (for each of the available choices).

Allowing the server to fix a set of choices without any further variability in messages avoids the headache of downgrade attacks.

[hugokraw]

@huitseeker Accepting unauthenticated parameters from the server can allow some form of downgrade attack as I mentioned before in this thread (sending low hardening parameters helps in an online dictionary attack where the attacker spoofs the server).

[chris-wood]

This was resolved by pinning configuration parameters as part of the configuration. In-band negotiation is (we believe) too complex to justify the cost. Closing as resolved.

[hugokraw]

How does the client learn the configuration? If the client is an application like Facebook I can see that the app on the user side has these parameters wired in. What about browser-based login with clients that were not pre-configured? Are you intentionally not supporting this case? One could transmit ciphersuite (and even parameters) in the envelope (which come authenticated). Even just a hash of the configuration in the envelope would defend against rogue/downgraded configurations.

[kevinlewi]

The general philosophy that I think would be helpful to maintain in terms of "what should go in the envelope" is that: only the minimum necessary in order for the OPAQUE protocol to function -- therefore, the skU parameter belongs there. I'm hoping that if an application wishes to transmit ciphersuite information and harden parameters in the envelope, they can instead make use of the export_key parameter as a key for authenticated encryption.

What about browser-based login with clients that were not pre-configured? Are you intentionally not supporting this case?

I think that this describes a less popular potential application of OPAQUE, which is why I would be hesitant to incorporate parameters that specifically support this into the envelope. At the same time, there is still the flexibility from the application layer to use export_key for this purpose.

@hugokraw let me know what you think! Also cc: @chris-wood since we had a discussion about this in the past as well.

[hugokraw]

Configuration information that may impact the derivation of RwdU cannot be protected by export_key. It is too late for that (e.g., in setting the hardening parameters or the algorithms with which export_key is derived and/or used.

The point of using the envelope to transmit parameters is that it is the only information the client gets in an authenticated way. Actually, in the case of OPAQUE over TLS, the server will first authenticate using a TLS certificate. In this case, the server can transmit hardening and other parameters to the client authenticated under the certificate. We should not do anything now that will make it difficult to accommodate such configuration information in the over-TLS case.
What do you think @chris-wood ?

[chris-wood]

I think what we have now is suitable for the TLS case. The future TLS spec can define how harden parameters are encoded and transmitted. And the client, if it supports those parameters, can use them. (In other words, the parameters part of the configuration, and the future TLS spec would just define how to express and choose the configuration.)

I don't think anything else needs to be done with respect to harden parameters in this particular spec.