CTAP draft feedback: CABLEv2 tunnel encryption uses non-standard DH algorithm

[AlfioEmanueleFresta]

Hi all.

I'm not sure if this is the right place to leave feedback on the March 21st, 2023 draft of the CTAP spec. This draft points at the fido-alliance/fido-2-specs repository for issue tracking, however this appears to be private (I can't access it).

I'm implementing the CABLE v2 transport (now Hybrid Transports) from the CTAP spec in my project, xdg-credentials-portal (platform APIs for the Linux desktop).

The tunnel to the authenticator device requires a Noise handshake to be performed over a WSS tunnel. However, the Noise protocol in use appears to be somewhat non-standard. Specifically, it uses P256 keypairs for key exchange, which is not part of the set of DH algorithm defined in the Noise Protocol Framework doc. This means that most off-the-shelf Noise library implementations cannot be used, and instead implementers are required to familiarise with details of the Noise protocol and use the low level primitives (e.g. MixHash, MixKey) as described in the CTAP spec - which I'm now doing. This might increase friction to implement the spec, and chances that subtle security bugs are introduced in implementations.

Why is P256 used in the draft spec over widely supported Noise DH options (Curve25519, Curve448)?

Is there an opportunity to simplify the spec, so as to delegate as much as possible of the Noise handshake to other, existing standards?

Thanks in advance!

[serianox]

I have many reason to prefer Curve25519 over secp256r1, but:

• secp256r1 was, and is still is, more widely supported than Curve25519, including in secure crypto-coprocessors; it also always has been a mandatory building block of FIDO since the first iterations,
• secp256r1 is recognized by many governments and institutions worldwide, it makes certification much easier, e.g. if you go through FIPS or ENISA.