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.
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.
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).
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.
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.