Re: [TLS] Curve25519 and TLS

[Watson Ladd <[e-mail]>]

On Thu, Jun 26, 2014 at 1:18 AM, Bodo Moeller <[e-mail]> wrote:
> 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.

Yes, we could make EMSE a dependency of Curve25519. Or we could change
the way we compute
the PMS to avoid doing this: I proposed this solution because its very
simple for some implementations.

What do we gain from having the PMS calculated the same way for each curve?
>
> (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.)

This is a mistake in the design. Unfortunately I can't go into details
right now.

Sincerely,
Watson Ladd
>
> Bodo
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin