Re: [kitten] complementary OPAQUE SASL mechanism draft

[Nadja Reitzenstein <[e-mail]>]

> For example, the PBKDF2 iteration count for
> SCRAM.  There is no reliable way to recover and retry with other
> parameters.  The problem was introducing an unecessary parametrization.

What exactly is the failure pattern you describe here? A client doesn't 
have to pre-compute anything before it receives the iteration count from 
the server, and I have not yet met an implementation of PBKDF2 that 
couldn't be configured in its iteration count.
The only problem I can think of right now is when a client is storing 
the expanded Client- & ServerKey instead of caching the password itself. 
Which doesn't apply to OPAQUE as there is no similar caching that can be 
done without impacting protocol security — the password is directly 
passed to Blind which should use a different value for each 
authentication. (Thinking about it this is definitely a security 
relevant point that I should mention in my draft!)

> It is often easier to introduce two sets of SASL mechanisms FOO-FOO and
> FOO-BAR, withou no further sub-parameters or sub-negotiations, and get
> that to work in applications than to introduce a family FOO-* and modify
> applications to support the kind of sub-negotiation and per-mechanism
> parametrization.

I personally don't see the drawback of allowing parameters for the KDF 
to be transmitted, but if there's consensus against it I'm also not 
opposed to have the parameters fixed. The argon2 RFC does specifically 
mention a suggested configuration that we can refer to for this.


~Nadja