The (de)merits ot making checks you don't have to make

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

It seems reasonable, but it's a misplacement of responsibility. A necessary condition for the crypto layer to be correct is that it solves padding problems 100%, without leakage. If the crypto layer has a problem where padding problems leak onto the application layer, then the crypto layer has a problem.

There's just one situation where I can perceive these checks to be possibly useful: if you're communicating with an implementation that has some kind of bug, where it's going to write over its own buffers and allow an attacker to tweak the packet that is sent. But this is another misplacement of responsibility. The responsibility to not be compromised lies with each program; not with applications that communicate with it. And it doesn't cover all compromise. Even if you make these checks, a fully compromised program would not trigger this type of check.

So you're going out of your way to make sure things are "right" that are not your responsibility to make right, and you don't even have a way to know your judgment was appropriate.

It's like being a neighborhood busybody. Like people who are inclined to call the police on their neighbors for anything that looks "slightly fishy". Except they don't have information, and it's always something innocent, and their completely normal neighbors must repeatedly deal with police. And the police shoot the family dog for no reason.


----- Original Message -----
From: Peter Gutmann 
Sent: Friday, November 6, 2015 03:02
To: denis bider ; ietf-ssh%netbsd.org@localhost 
Subject: RE: OpenSSH sabotages protocol extension

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

>What possible purpose does this serve?

It's perfectly sensible, if the spec requires that a packet be x, y, z then
getting a packet containing x, y, z, extra garbage is at best a sign of data
corruption, at worst a sign of an active attack.  Rejecting the packet and
closing the connection is good practice, it makes it harder for an attacker to
use you as an oracle.

For an example of what happens if you do ignore extra garbage at the end of
your data, look at the padding attacks on PKCS #1...

Peter.