Re: [TLS] Curve25519 and TLS

[Bodo Moeller <[e-mail]>]

[Resending my earlier message because apparently it hadn't made it to the
list. If you read the quotes in Watson's reply to this, there's nothing new
here.]


---------- Forwarded message ----------
From: Bodo Moeller <[e-mail]>
Date: 2014-06-26 10:18 GMT+02:00
Subject: Re: [TLS] Curve25519 and TLS
To: Watson Ladd <[e-mail]>
Cc: "[e-mail]" <[e-mail]>


Watson Ladd <[e-mail]>:

 TLS with ECC computes the premaster secret as H(abg) where g is the
> generator of the group, and a and b are the ephemeral exponents.
> Because of protocol weaknesses, this premaster secret must be
> "contributory": neither side can be allowed to dictate it.
>

[...]

> The solution is to follow the advice on contributory behaviour and
> disallow a fixed list of public keys, namely those of small order.
>

Good point.  Given that the cofactor present in your secret key guarantees
that you'll end up in a prime-order group (regardless of how the peer's
input was chosen), I think you'd rather want to check the ECDH result
instead of checking against that larger blacklist of public keys.

Alternatively we can compute the premaster secret as the hash of H(ag
> | bg | abg): I have not yet confirmed that this solves the problem.
>

Hm, this looks like something that rather belongs into the premaster secret
=> master secret step.  If you have this there (such as when you're using
the proposed Extended Master Secret Extension
[draft-bhargavan-tls-session-hash-00]), including the public keys here too
would be redundant.  If you'd normally be doing a public-key check or an
ECDH result check, you could just skip this check if the protocol no longer
has a need for such protection.  In contrast, if you hash those additional
inputs when computing the premaster secret, that's not something you could
remove without affecting compatibility.

(On the flip site, of course, if an implementation omits a check that's
necessary for security reasons in the protocol that you're using, you
wouldn't normally notice interoperability problems as a result.  In
contrast, if the protocol has those additional hash inputs, implementations
couldn't get that wrong without failing to interoperate with others.
 However, there are many other more complex essential security checks that
we trust implementations to get right, so the extra protocol complexity for
this particular case doesn't seem warranted.)

Bodo