Re: Curve25519/448 key agreement for SSH

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Regarding the check, it seems to me that SSH has an advantage over TLS, in that it includes hashes of negotiation content in the key exchange. Therefore, perhaps SSH is not as vulnerable to attacks of this type (such as the Triple Handshake attack in TLS).

It still seems a better practice to check than not to check, though, just in case foresight is not 20/20. Surely, if the value is zero, the other party is sabotaging the key exchange (chances of this occurring randomly are astronomically close to zero). If the other party is sabotaging key exchange, it's doing this for some reason. I'm not sure that we need to know the reason in order to refuse to cooperate.


----- Original Message -----
From: Simon Josefsson 
Sent: Wednesday, November 18, 2015 14:39
To: ietf-ssh%netbsd.org@localhost 
Subject: Re: Curve25519/448 key agreement for SSH

This is another update, clarifying the encoding issue a bit further and
improving language (thank you Denis).

  https://tools.ietf.org/html/draft-josefsson-ssh-curves-02

A discussion on CFRG came up recently about checking for the all-zero
shared secret.  Does anyone know if libssh or OpenSSH (or anyone else)
performs this check?  Not doing that has apparently led to real security
problems.  For more background, see:

  http://thread.gmane.org/gmane.ietf.irtf.cfrg/6228

Thoughts on whether we should add a MUST to require checking the derived
secret for the all-zero value?

/Simon