Updated Section 11 online

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Folks,

I've redone the Section 11 incorporating Russ' comments and adding the
references to the Rogaway attack.

  http://www.employees.org/~lonvick/newssh010.html

If anyone cannot view this, or has difficulties viewing it, please send me
a note separately and I'll ship the plain-text version to you.

I'll start working on the comments provided by Joel with hopes of making
them available next week.  For those who may wish to propose helpful text,
here are the comments.

===
The paragraphs in the man in the middle attack section are awefully
long.  It might be more readable if there was a subheading for each of
the three cases that are currently paragraphs, so that each of the
existing paragraphs could be broken into multiple paragraphs.

[Note: I learned that a paragraph is a separate thought in the whole of
the document reguardless of length.  I'll think about it.  (Kafka had a
way with paragraphs. ;) ]

newssh10.html appears to have lost some changes to the mitm attack
section that were made in newssh9.html, such as starting off the
paragraph with ``There are {two,three} cases to consider''

[Note: All fixed up now in 010.html]

There are several issues with the host key of a mitm being presented
instead of the real host that are not adaquately discussed in the
current text, some of which I think have been previously brought up in
discussion on this list:

1) There should be an explicit discussion of the problem that in the
real world, hosts occasionally get reinstalled, CNAMEs sometimes move
around, etc.  When this happens, people often learn that the meaning
of the man in the middle attack warning is simply that they should
delete the relevant line of their known_hosts file.  The standard
usage of bare ssh host keys is such that, given only the message from
the ssh client, it is impossible to figure out whether there is a mitm
attack or a legitimate host key change, and that only with a lot of
user education and increased user paranoia or a better mechanism is
this vulnerability going to go away.

2) It would be useful to discuss how if public key userauth is used,
the mitm will not be able to authenticate to the real server as the
user, because the signature will be against the wrong session
identifier.

3) It would be useful to mention that if agent forwarding is enabled,
and if the host key of a bogus server is accepted by the client, the
man in the middle *will* be able to authenticate to the real server.
It should probably be recommended that agent forwarding be disabled by
default.
===

Thanks,
Chris