This bug becomes noticeable when the extension following the "supported point
formats" extension has a number starting with 0x01, which is the case of the
EC J-PAKE extension, which explains what I noticed the bug now.
This will be immediately backported to the stable branches,
see the corresponding commits for impact analysis.
This is more consistent, as it doesn't make any sense for a user to be able to
set up an EC J-PAKE password with TLS if the corresponding key exchange is
disabled.
Arguably this is what we should de for other key exchanges as well instead of
depending on ECDH_C etc, but this is an independent issue, so let's just do
the right thing with the new key exchange and fix the other ones later. (This
is a marginal issue anyway, since people who disable all ECDH key exchange are
likely to also disable ECDH_C in order to minimize footprint.)
When we don't have a password, we want to skip the costly process of
generating the extension. So for consistency don't offer the ciphersuite
without the extension.
The Thread spec says we need those for EC J-PAKE too.
However, we won't be using the information, so we can skip the parsing
functions in an EC J-PAKE only config; keep the writing functions in order to
comply with the spec.
I'm not sure this is necessary, because it is only multiplied by xm2 which is
already random and secret, but OTOH, xm2 is related to a public value, so
let's add blinding with a random value that's only use for blinding, just to
be extra sure.
- reference handshake tests that we get the right values (not much now, but
much more later when we get to deriving the PMS)
- random handshake in addition tests our generate/write functions against our
read functions, that are tested by the reference handshake, and will be
further tested in the test suite later against invalid inputs
