Re: [ssh] Host key sync - "global-requests-ok" extension

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

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

>You're focusing on an outdated aspect of the spec instead of widely known
>best practice.

I'm trying to deal with the fallout from existing implementations that only
do what's in the base RFCs.

>CBC algorithms are known to have security problems in the way they are used
>in SSH. They haven't been recommended for use in years.

Only if they're badly implemented.  SSH packets have so much known plaintext
at the start that it's pretty easy to reject guessing attacks, or at least
reduce the success rate to the point where it's not useful to an attacker.  In
addition it's a chosen-plaintext attack, which for many implementations of SSH
(e.g. embedded and SCADA) is essentially impossible.

The problem with disabling the MTI algorithms is that a lot of implementations
don't look beyond 4251-4254, so by only allowing -CTR, which they don't do,
it's forcing them to fall back to things like FTP and (shudder) TFTP.  In
other words instead of saying "we'd prefer -CTR, but will go with -CBC if you
can't do that, which unless you've got a pretty broken implementation is no
less secure", the server is saying "if you can't do -CTR, we'll force you to
fall back to what's pretty much the least secure file transfer protocol there
is (TFTP)".

The reason why my code warns about -CTR only servers is because I got tired of
answering questions along the lines of "X works with Y, but not with OpenSSH,
what's wrong?".

>If we ship the SSH Server with CBC algorithms enabled, we get support cases
>from users failing security scans.

Ah, I can see that'd be a problem then.  Can you beat the scanner vendor over
the head to fix the scanner?  I had to do that when someone's scanner reported
an OpenSSL vuln in my code.

Peter.