Neither (A) nor (B) are concerns. In (B), the authors are just unfamiliar with HKDF. HKDF is a standard way to use HMAC for key derivation (RFC 5869).
(C) is the observation that you could lie and claim someone else's fingerprint (print it on your business card, for example). This doesn't accomplish much, but is a general issue with fingerprints (e.g. OTR, SSH).
You can try to bind more of the context (e.g. hash more identifying information into the session key or MAC), but this makes things rigid, particularly if parties might be contacted under aliases (e.g., imagine if SSH servers needed to be configured with all possible DNS names they might be contacted under, and rejected others).
But even then, you can't 100% prevent this - if the protocol "binds" the phone number, you can lie and claim someone else's phone number, or name, etc.
FWIW this is on hold until I know for sure what high-security-margin curve to use. I'd like this to be a "one-ciphersuite-fits-all" protocol, which puts a lot of pressure on getting that choice right.
In addition to DJB's Curve41417 (not yet implemented), Mike Hamburg's Goldilocks-448 curve looks pretty good, so I'm waiting for that to shake out.
Those two being the choices, I'd go for 41417: arithmetic modulo 2^414-17 is (to me, at least) simpler, and smaller Edwards coefficient. Performance should be in the same ballpark, if not faster.
I wonder if a higher security margin curve is really required here, though. (Block) ciphers usually have to worry about multi-target attacks; 128-bit security starts to feel small in that scenario. But curves don't have that problem: you need to actually do 2^128 computation even in the multi-target case, so it seems less necessary to insist on >256-bit curves. What's the rationale behind the higher security margin curves?
Performance should be in the same ballpark, but I'd rather go with whichever achieves its security level most efficiently. Goldilocks looks good by that metric [1], so I'm curious how a Curve41417 implementation compares.
The rationale for an "extra-strength" curve is the hope it might resist future cryptanalytic breakthroughs. The extra bits aren't needed for brute force, but if some cryptanalysis comes along in 20 years and lops a bunch of "security bits" off, you might be glad you had extra ones...
That's a hard thing to quantify, but if we can get, say, 96 extra security bits for only a ~3.5x slowdown over Curve25519, it seems worthwhile.
I know you are waiting for the curve thing to get settled but it's too bad there's not a C implementation in the repo right now. Today I'm working on a project that could clearly benefit from Noise but since it doesn't exist I have to use CurveCP and try to work around the problems you've identified myself.
I completely get where you're coming from on the "one ciphersuite to rule them all" problem but as an early adopter I would happily use curve25519 as a stopgap until you decide what the One True Curve should be. Instead I have to do my own CurveCP implementation now and then maybe rip it out later.
Probably a good curve too (nice Mersenne prime, so fast reduction). But I'm not sure it fits into processor words as efficiently as Goldilocks (I'm not an expert here, but someone was trying to explain this to me).
But yeah, those might be 3 good candidates for a higher-security curve (Curve41417, Goldilocks, E-521).
That would be great, we have a mailing list interested people should monitor, we'll definitely let people know once things get far enough for sites to start testing the waters.
Regarding certificate pinning: TACK is a different "style" of pinning, it lets you pin to a self-managed signing key instead of certificate keys. So it gives you more control and security than CA pinning, if you're willing to assume more key management responsibilities (storing a TACK private key, and using it to sign new TLS keys).
I think there's room for both approaches: I'd like to see CA pinning be made easy enough that most sites could deploy a fairly safe, simple pin to popular CAs, while high-security sites make use of TACK pins.
We have support for a"ServerInfo" file checked into OpenSSL. This is a file with PEM blobs that can specify TACK and similar data (e.g. Certificate Transparency) that an OpenSSL server will return to clients if requested. This is a generic mechanism for TLS Extensions instead of TACK-specific, but it's what we need.
It will hopefully appear in OpenSSL 1.0.2. We'll be submitting Apache patches for it shortly. Daniel Jackoway (in this thread somewhere) is working on the NSS (client-side) corollary.
(C) is the observation that you could lie and claim someone else's fingerprint (print it on your business card, for example). This doesn't accomplish much, but is a general issue with fingerprints (e.g. OTR, SSH).
You can try to bind more of the context (e.g. hash more identifying information into the session key or MAC), but this makes things rigid, particularly if parties might be contacted under aliases (e.g., imagine if SSH servers needed to be configured with all possible DNS names they might be contacted under, and rejected others).
But even then, you can't 100% prevent this - if the protocol "binds" the phone number, you can lie and claim someone else's phone number, or name, etc.