John Hawkinson <jhawk@MIT.EDU> wrote on Fri, 28 Nov 2003
at 18:55:30 -0500 in <20031128235530.GQ3302@multics.mit.edu>:

> My [possibly flawed] understanding is that using 'none' causes
> authentication to be insecure, not just encryption. So not only might
> it compromise the current transaction, it could compromise future
> transactions.

Upon review of old mail to openssh-unix-dev, I conclude that the
'none' cipher allows MITM attacks under ssh v1 as well as connection
hijacking, and they are reason to be concerned
(<Pine.LNX.4.10.10010130843390.32433-100000@syrinx.oankali.net>,
<00a301c17f73$a5c014c0$1701000a@effugas>, and
<050d01c10440$5cd18ea0$6b00040a@na.cisco.com>).


As I understand it, it is not in openssh for both that reason, as well
as the belief of the openssh maintainers that it is not necessary, and
that using arcfour ought to get sufficient speed for most applications
(<Pine.LNX.4.33.0112111251430.18366-100000@mothra.mindrot.org>).


Additionally, the current protocol draft, draft-ietf-secsh-transport-17.txt,
in Section 5.3 (Encryption) reads:

|      none             OPTIONAL          no encryption; NOT RECOMMENDED
...
|    The "none" algorithm specifies that no encryption is to be done.
|    Note that this method provides no confidentiality protection, and it
|    is not recommended.  Some functionality (e.g. password
|    authentication) may be disabled for security reasons if this cipher
|    is chosen.

The current architecture draft, draft-ietf-secsh-architecture-15.txt,
in section 9.2.1 (Transport -> Confidentiality) reads:

|   The "none" cipher is provided for debugging and SHOULD NOT be used
|   except for that purpose.  It's cryptographic properties are
|   sufficiently described in RFC 2410, which will show that its use does
|   not meet the intent of this protocol.


--jhawk
  (Who is not advocating a change to NetBSD's ssh, just trying to
   introduce some facts.)