| This paper, though, shows that doing an su over an ssh connection leaks a
| lot of information about the su'ing password. That snooper learns both the
| exact password length, and info about the letters of the password.

...

| With direct root logins, the only thing which gets leaked is if the password
| has eight characters or not.

Well, just as an aside, there are lots of exceptions to both these
assertions.  The one that motivated the reply is that a snooper must
first know that the snooped party is actually running su, which is
somewhat hard in the case where only 1/2 the traffic is being seen.
(It's easier if you see three minimal-data packets a return larger
packet ("Password:" is great known cleartext), and then some number of
minimal-sized packets with only ACKs, and with a larger data packet
("...# ", with the last two being great known cleartext, and you can
also make some assumptions about "...") after the string of ACKs.
In a "log in and immediately su" transaction, this is much easier
to identify, even without seeing both directions.

Direct root logins have the advantage to the attacker that the
very first exchange is going to have some known cleartext, and 
the first obviously-interactive set of keystrokes are almost
certainly the password, against which one can play all sorts of
timing analyses which may or may not help sort the order of brute-force
attacking to achieve a reduction in mean-time-to-crack.

When you can discover an "su" in progress, which is the additonal
hard part, you have exactly the same problem to sort out as a
direct root login, where a password is required.

"Chaff" and artificial delay (even beyond Nagle) significantly
strips away useful sorting information in either case. 

Public-Key direct root logins are even better, although one
can look for the enter-unlock-code dialogue if it happens across
a network (e.g., recursive ssh (ssh hosta ssh hostb command)).

Finger travel time analyses are less spooky when one considers
the amount of noise introduced through ordinay routing equipment.
Even on LANs, any kind of transmit delay (other traffic) will
strip out timing information, as will the poor resolutions (4ms+)
one gets when timing packet arrival times on many platforms.

However, a long-term sniffer which is not defeated by chaff or
constant queueing noise, can probably make pretty good guesses
at what's being typed, especially if virtually every keystroke is
in its own packet.  (i.e., people don't suddenly improve or disimprove
wrt how they type, touch typists tend to be pretty consistent
according to qwerty theory, and that kind of thing).

Again, the answer here is not so much handwringing about
whether to allow root login or whatever, but rather what
to do about the fact that timing analyses are probably
useful in attacking encrypted interactive data streams,
be they ssh or ipsec or kerberos, especially where 
there is some degree of known plaintext at the start of
such a stream, or any other absolutely predictable moment.

"Chaff" is probably the answer.

	Sean.

P.S.: Wrt the specific root login issue, the salient point is that
      it DOES require someone to specifically turn on root login,
which general wisdom seems to think is insecure in enough cases that making
naive users think hard about reversing the flag in sshd as in every other
possible login-producing server is a good idea.  A few sentences
explaining why the flag is off by default as comments just before
the flag itself is possibly helpful to new users.  Comment text
of any variety surely is not much inconvenience to someone who
wants to defeat the config defaults when settingup a new machine.
I just find it hard to believe that having to write a couple lines
in a script/instruction-sheet driving an initial setup for a further
non-standard cross-network installation process should be a compelling
reason not to change the flag's default to no.