>The first thing you learn in any infosec class is to reject invalid inputs, and check return values for errors, even if there’s no obvious exploit in sight. Doing this is sometimes called “defense in depth” or “best practice”.
Rejected invalid inputs is often a good idea, but it isn't defense in depth and it isn't automatically best practice. Always doing something because you "learned it an infosec class" is dogmatic.
>The point of Diffie-Hellman is that both key shares should equally contribute to the shared secret, so that the protocol doesn’t allow key control, a desirable attribute of any authenticated key agreement protocol, as discussed in this MQV paper. If the protocol allows a peer to force the shared secret to be zero, or more generally to lie in a subgroup, then the said peer can surreptitiously weaken the protocol’s security (objection: “but why would a peer be malicious?”).
This point was refuted earlier in the article. "If a peer is malicious, than they can do much worse than sending invalid keys".
> It’s costless: adding a zero check is ten lines of code tops, which is unlikely to introduce new vulnerabilities nor to hurt performance.
Ten lines of code isn't costless, it is low cost. Even if it were costless, it would still be better to not do it unless there is a compelling reason to do it.
> It reduces the risk of non-obvious attacks. Take Signal’s protocol, for example. If Alice generates all-zero prekeys and identity key, and pushes them to the Signal’s servers, then all the peers who initiate a new session with Alice will encrypt their first message with the same key, derived from all-zero shared secrets—essentially, the first message will be in the clear for an eavesdropper. Alice can deny being malicious, arguing that her PRNG failed. That’s just an example scenario—granted, far-fetched—but there might be others, and checking for invalid keys is probably easier than proving that they will never be exploited.
Not only is this not a "non-obvious attack", this is the only possible attack. The only thing that adding a check to prevent a zero key can do is prevent someone from using a zero key. By the way, this attack gains nothing. Any malicious user already has the ability to publicize any messages sent to them.