HIP and Curve25519 - RFC 7748

We have an RFC now for Curve25519 and it behooves us to start looking at 
it and what it means to HIP.  I definitely need to look at it for DEX as 
I don't have to wait for Ed25519 which is moving along as well.

I believe an important part that impacts HIP in RFC 7748 is:

    Designers using these curves should be aware that for each public
    key, there are several publicly computable public keys that are
    equivalent to it, i.e., they produce the same shared secrets. Thus
    using a public key as an identifier and knowledge of a shared secret
    as proof of ownership (without including the public keys in the key
    derivation) might lead to subtle vulnerabilities.


Ouch!  That is us, I believe.

So this points to KEYMAT changes.  If you look elsewhere in 7748 you see 
in 6.1:

    Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9))
    as a shared secret.  Both MAY check, without leaking extra
    information about the value of K, whether K is the all-zero value and
    abort if so (see below).  Alice and Bob can then use a key-derivation
    function that includes K, K_A, and K_B to derive a symmetric key.

So this is a bit different requirement for KEYMAT.  Again, it definitely 
impacts DEX, but also BEX.  I believe.

One item not mentioned that is very important in DEX is ephemeral vs 
static key usage.  What concerns are there with static key usage?

Any comments on working to include this curve work?  Also be on the 
watch for BLAKE2 as the hash to use over SHA256.