Setup agreement on a "standard form" of CPace for ristretto255 and add it to the I-D

[BjoernMHaase]

Simply concatenating variable-length, possibly attacker controlled values as the
I-D suggests is dangerous. For example, the (idA, idB) pairs ("ax", "b") and
("a", "xb") would result equivalent. Instead, this implementation uses HKDF to
separate secret material, salt, and context, and a uint16-length prefixed
serialization for CI.
Thank's for pointing this out.

Checking for the neutral element should be manadtory in my perception and should be explicitly included into the code, even if some part of the ristretto implementation also checks for this.

Regarding the SID agreement, the recommended way would be that the SID is passed to CPace by a higher-level protocol entity, e.g. on the application level. The implementation is then guaranteed that the specific CPace run is uniquely linked to this session on both sides. This avoids problems in the style of the "selfie-attack" on TLS with PSK.

If there is no such higher-level SID handling, one could just make the initiator sample a random string of appropriate length, e.g. 16 bytes.

I'd appreciate any feedback regarding the readability and structure of the CPace I-D. I don't have much experience with writing this type of document, and any feedback would be helpful.

Yours,

Björn.

[BjoernMHaase]

Link to the general collection of feedback regarding the CPace draft.

BjoernMHaase/AuCPace#3

Link to a recent related post on the CFRG mailing list

https://mailarchive.ietf.org/arch/msg/cfrg/jwV8c0BWwXdhQkPRB7yRz_zFmAg/