Subject: secsh meeting in pittsburgh: call for agenda items.

From: Sami Lehtinen <[email-masked]>
Date: Sun, 23 Jul 2000 02:20:11 +0300 (EEST)

Bill Sommerfeld, on July 20. 2000, wrote:
  : Now would be a good time for folks to do a careful review of the four
  : existing drafts:
  : 
  : 	draft-ietf-secsh-architecture-05.txt
  : 	draft-ietf-secsh-transport-07.txt
  : 	draft-ietf-secsh-userauth-07.txt
  : 	draft-ietf-secsh-connect-07.txt
  : 
  : Please send comments to this list.

As Markus Friedl, Niels Möller and I have already commented on this
list, I will be removing the unnecessary ``length'' fields from the
certificate and public key encoding. It will also be removed from the
encoded signature. This is because the signatures and public keys are
encoded as strings in all the messages they are used.

This change will only affect the transport draft.

Regards,
-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 23 Jul 2000 17:35:49 -0400

>This change will only affect the transport draft.

Ought this not receive broader WG discussion before being made ?

At least in theory this is an open IETF standard, rather than
the private specification of SSH Communications Security... :-)

Ran
[email-masked]

---

From: Tatu Ylonen <[email-masked]>
Date: Mon, 24 Jul 2000 00:40:13 +0300 (EET DST)

I'm writing a draft on Kerberos V5 support in SSH2, and would like to
have a short presentation/discussion on that at the meeting.

The general idea is very simple:

Two new authentication methods, "kerberos" and "kerberos-tgt", plus
allowing the user name passed in the authentication protocol to be in
the form "<user>@<realm>", in addition to just user name.

The "kerberos" method passes a "host" ticket, whereas the
"kerberos-tgt" passes a ticket granting ticket.  The only
method-specific field in the authentication packets is a string
containing the ticket.

If "user@realm" syntax is used for the user name, it should be mapped
to a local name.

The "password" method should also check for kerberos passwords.

If successfully authenticating using either "kerberos-tgt" or
"password" (using kerberos passwords), the ticket granting ticket
should be stored in the user's credentials cache (as if kinit had been
done for the user).

I should have the draft ready in a couple of days (or maybe even later
today), and I will send it to this list before the IETF.

    Tatu

-- 
SSH Communications Security           http://www.ssh.com/
SSH IPSEC Toolkit                     http://www.ipsec.com/
SSH(R) Secure Shell(TM)               http://www.ssh.com/ssh

---

From: Sami Lehtinen <[email-masked]>
Date: Mon, 24 Jul 2000 17:47:48 +0300 (EEST)

Tatu Ylonen, on July 24. 2000, wrote:
[length field in signatures and certificate/public key encoding]
  : > Ought this not receive broader WG discussion before being made ?
  : > 
  : > At least in theory this is an open IETF standard, rather than
  : > the private specification of SSH Communications Security... :-)
  : 
  : Markus is working on OpenSSH, and Niels is doing the GNU LSH
  : implementation.  Neither of them works for SSH Communications
  : Security.  In any case, this *is* the secsh WG mailing list... :-)

Also, the change has already been discussed here at length. If you
(RJ) have differing views, please post them to the list.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Jul 2000 10:41:29 -0400

> >This change will only affect the transport draft.

         I'll try again and maybe be more clear.  

         Various folks (including my employer and its myriad
customers) have already SHIPPED and DEPLOYED SSHv2, therefore 
changing the protocol on the wire is highly undesirable at
this point in time.  If we are merely sending data that isn't
needed, but is not actually incorrect or harmful, we probably
ought not be changing the spec (and thereby removing what
interoperability exists at present).  

         There are more than 3 implementers at this point, 
so ALL changes ought to go through a normal IETF "propose to 
the mailing list", "list discusses proposal", then "document 
is changed if and only if  there is clear consensus to make 
the change" process.

         Generally speaking, the goal at this point ought to be
to AVOID changing the protocol, though updating documents to
reflect the as-built, as-shipped, as-deployed protocol would
obviously be useful and a good thing.  If there is a specific
flaw in the currently specified protocol, then that ought to
be outlined before the WG (as a whole, not one or two individuals)
so the group collective can figure out how to proceed.

         All IMHO.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Jul 2000 11:02:01 -0400

>(RJ) have differing views, please post them to the list.

         I'll assume that those emails didn't reach me due to some
SMTP weirdness.  Any road, I haven't seen them.  I've forgotten
where the list archive lives, maybe someone can throw me a clue
privately ? :-)

         I do object to changing the protocol on the wire because
it adversely impacts what interoperability exists at present.

         I have commit access to an SSHv2 implementation that has 
already shipped and is in daily (hourly ?) use by customers.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Jul 2000 11:18:25 -0400

At 10:58 24/07/00 , Sami Lehtinen wrote:

>Okay, let's see. LSH and OpenSSH and our SSH implementation (from
>v.2.2.0) follow the more "logical" style, ie. the length field is
>omitted.
>
>That means, if the draft isn't changed, atleast 3 implementors will
>have to change their implementation.

I'll rescind the objection if this is merely changing the
document to reflect the majority of the running code 
(as the above seems to indicate).  This was not clear in
earlier comments that I have seen.

Given that I'm not receiving all of the notes from the list
and my other correspondents aren't indicating that they are
having trouble reaching me, maybe we could migrate the list over 
to ietf.org ?  This would also have the side-effect of making
the list auto-archived with the archive accessible via web
from www.ietf.org.  Reactions ?

Ran
[email-masked]

---

From: Dug Song <[email-masked]>
Date: Mon, 24 Jul 2000 11:39:20 -0400 (EDT)

> have a short presentation/discussion on that at the meeting.

quick question - has any consideration been given to GSS as an
authentication mechanism for SSH2? this is how krb5 support is
actually implemented in FTP (via SASL), RPC (via RPCSEC_GSS), etc.

the Globus folks have a GSS patch for ssh-1.2.27, if you're interested in
how this might work:

	ftp://ftp.ncsa.uiuc.edu/aces/gssapi-ssh/

-d.

---
http://www.monkey.org/~dugsong/

---

From: Sami Lehtinen <[email-masked]>
Date: Mon, 24 Jul 2000 17:58:58 +0300 (EEST)

RJ Atkinson, on July 24. 2000, wrote:
  :          Various folks (including my employer and its myriad
  : customers) have already SHIPPED and DEPLOYED SSHv2, therefore 
  : changing the protocol on the wire is highly undesirable at
  : this point in time.  If we are merely sending data that isn't
  : needed, but is not actually incorrect or harmful, we probably
  : ought not be changing the spec (and thereby removing what
  : interoperability exists at present).  
  :
  :          There are more than 3 implementers at this point, 
  : so ALL changes ought to go through a normal IETF "propose to 
  : the mailing list", "list discusses proposal", then "document 
  : is changed if and only if  there is clear consensus to make 
  : the change" process.

These have already been established, though I don't know whether you
have access to those messages. The change hasn't yet been made, as
the responsible person for this change (=me) was in vacation.

  :          Generally speaking, the goal at this point ought to be
  : to AVOID changing the protocol, though updating documents to
  : reflect the as-built, as-shipped, as-deployed protocol would
  : obviously be useful and a good thing.  If there is a specific
  : flaw in the currently specified protocol, then that ought to
  : be outlined before the WG (as a whole, not one or two individuals)
  : so the group collective can figure out how to proceed.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 24 Jul 2000 13:07:13 -0500

> have a short presentation/discussion on that at the meeting.

Have you also considered a GSSAPI authenticaiton, rather then Kerberos
directly? (We talked breifly at the RSA conference last spring on this.)  

Would you also like to say a few words at the new Kerberos WG on
Wednesday 1530? Let me know if you would. 

>                   Jeffrey Altman * Sr.Software Designer
>                  The Kermit Project * Columbia University
>                612 West 115th St * New York, NY * 10025 * USA
>      http://www.kermit-project.org/ * [email-masked]

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 24 Jul 2000 18:35:54 -0400

{working group chair hat on}:

while this isn't the case for the change which sparked this (there
appears to be consensus that the proposed change to delete the
duplicate length field is appropriate), I'll underline what Ran just
said:

I am personally aware of several other sshv2 implementations besides
the 3 everyone knows about (SSH, Inc, LSH, and openssh).  I'm sure
there are others; it would be useful to hear from other SSHv2 protocol
implementors if they have something to say..

				- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 24 Jul 2000 18:38:18 -0400

> today), and I will send it to this list before the IETF.

Since we're already past the internet-drafts deadline for this
meeting, there's no need to go to extreme lengths to rush this out the
door before the pittsburgh meeting..

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Mon, 24 Jul 2000 21:29:58 -0600

Bill Sommerfeld, on July 20. 2000, wrote:
> Now would be a good time for folks to do a careful review of the four
> existing drafts:
> 
> draft-ietf-secsh-architecture-05.txt
> draft-ietf-secsh-transport-07.txt
> draft-ietf-secsh-userauth-07.txt
> draft-ietf-secsh-connect-07.txt

draft-ietf-secsh-connect-07.txt currently includes a reference to
SSH-AGENT:

  4.4.  Authentication Agent Forwarding

  It is RECOMMENDED that authentication agent forwarding is allowed even
  when either or both parties do not support the SSH authentication agent
  protocol [SSH-AGENT].

Does this document exist?

Is so, where can I download a copy?

If not, what are the current plans to address this?

Thank you.

Jeff P. Van Dyke
[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 25 Jul 2000 11:18:58 -0400

>   when either or both parties do not support the SSH authentication agent

Good catch.  There's also a reference to agent forwarding in the
architecture draft.

From a process standpoint, we cannot have unresolved external
references in the document..  this reference needs to be resolved, or
the refererences removed from the documents, before they can be
advanced into the standards track.

My personal opinion is that there should be a fifth draft to describe
the SSHv2 authentication agent forwarding protocol, plus external
references to the SSHv1 agent protocol.

> If not, what are the current plans to address this?

The document editors will need to answer this.

					- Bill

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 25 Jul 2000 14:36:18 -0500

> method-specific field in the authentication packets is a string

OK, I'm stumped.  How does the ssh server check the validity of a
TGT?  By getting a host ticket for itself from the KDC?  Then it must
have a sverice principal.  And if it has that, why not just require
the client to get the host-specific service ticket first?  It already
had to do a TGS exchange with the KDC in order to "forward" the TGT.

It looks like you're encouraging the client to pass its credential to
a server it can't have authenticated (by Kerberos) yet.

> should be stored in the user's credentials cache (as if kinit had been

Can't you provide a way for the client to *optionally* forward its
TGT after mutual client-server authentication has been done?

				Matt Crawford
(Now I'll have to look at the ietf-ssh archive to see if this has
already been answered.)

---

From: Markus Friedl <[email-masked]>
Date: Wed, 26 Jul 2000 00:49:58 +0200

> it adversely impacts what interoperability exists at present.

i don't consider this a 'change of the protocol on the wire'.
the current draft is just ambiguous and inconsistent, see
my previous e-mail.

-markus

Subject: Re: ssh-dss signatures
From: Markus Friedl <markus>
To: Niels Möller <[email-masked]>
Cc: [email-masked], [email-masked], Sami Lehtinen <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 22 May 2000 00:13:41 +0200

Hello,

On Sun, May 21, 2000 at 10:26:35PM +0200, Niels Möller wrote:
> Sami Lehtinen notified me of a bug in LSH's implementation of ssh-dss
> signatures. As I would like to have my interpretation of the spec
> confirmed, and as I suspect that also openssh may have the same
> problem (as it manages to interoperate with LSH), I'm writing to the
> WG list.
> 
> The transport draft, draft-ietf-secsh-transport-07.txt, defines an
> ssh-dss signature as
> 
>   uint32    length
>   string    "ssh-dss"
>   string    dss_signature_blob

The first field is omitted by OpenSSH as well as by SecureCRT
and from my experiments with other implementations of SSH2
it seems that ssh-2.1.0 and ssh-2.0.13 both omit everything but
	 dss_signature_blob
not even the size of the dss_signature_blob is included.

IMHO, the redundant field
	uint32    length
seems inconsistent with the overall design of all other
parts of the SSH2 specification so I would strongly support
the change of the signature specification to

	string    "ssh-dss"
	string    dss_signature_blob

Moreover, from reading the drafts now again it seems to me that the
above mentioned (redundant) uint32 length is identical to the uint32
length field from the "string signature of H".

Similar to this is the definition for "ssh-dss" from the same
transport draft:

	uint32    length
	string    "ssh-dss"
	mpint     p
	mpint     q
	mpint     g
	mpint     y

In all implementations that I could test (ssh-2.1.0, ssh-2.0.13,
lsh, SecureCRT, OpenSSH) the specified (redundant) length field is
_never_ sent across the wire.  e.g., in SSH_MSG_KEXDH_REPLY length
field from the string
	string    K_S, the host key
is again identical to the length field from the "ssh-dss" definition.

> The problem is the first field, which LSH omits. The signature is used
> for instance inside the SSH_MSG_KEXDH_REPLY message,
> 
>   byte      SSH_MSG_KEXDH_REPLY
>   string    server public host key and certificates (K_S)
>   mpint     f
>   string    signature of H
> 
> In LSH, this message looks something like this:
> 
>   SSH_MSG_KEXDH_REPLY (byte)
>   length of host key  (uint32)
>   host key data (byte array)
>   length of f
>   digits of f
> * length of signature (i.e. all below) 
>   7 (length of "ssh-dss")
>   "ssh-dss" (7 bytes)
>   length of signature blob (usually 40, and always even)
>   r digits (usually 20 bytes)
>   s digits (usually 20 bytes, but always the same length as for r)

This is the same encoding OpenSSH generates and expects.
SecureCRT expects the same format and it seems consistent
with there overall design (there is never a explicit length
field, only 'string'-type data has length fileds).

And again: I would strongly favour the removal of the
redundant length fields from the drafts since:
	1) They are not usefull at all. Why should n bytes of data
	   be encoded as: 
		uint32	n+4
		uint32	n
		n bytes data
	2) There is no public implementation of the drafts that includes
	   the redundant length field so
	3) Requiring the length field breaks all public implementations
	   of the drafts. This would hurt the acceptance of SSH2 much,
	   since it adds yet another layer of incompatibility.

> The extra length field is totally redundant here (and I believe it is
> equally redundant in all other places where an ssh-dss signature is
> used). I'm about to add it in LSH now, in order to comply with the
> draft, but I would also like the WG to give some consideration to
> removing the redundant length field in the definition of the ssh-dss
> signature.

As I said before, I see no reason why the length field is in the
drafts and I even think it refers to the length field from the
string encoding.

-markus

---

From: "Andersson, Mats" <[email-masked]>
Date: Thu, 27 Jul 2000 17:11:07 +0100 (IST)

Hi,

I'm the author of the MindTerm ssh1 client. I have implemented the sshv2
protocol also, currently only client side (interoperates with OpenSSH and
SSH Inc's sshd). Server side will be implemented later on, the development
have been stalled for over 2 months due to heavy workload.

The change proposed (signature) is (IMHO) a good one and should be made
"final", as someone else noted it's only an ambiguity in the draft that
would be "closed" (besides beeing trivial/logical anyway :-).

Generally, it's not very hard to change the implementation for basic stuff
like this, after all it IS a draft still. As long as the standard becomes
clean, shouldn't that be the main concern?

While I'm at it, it would be fun (useful?) if the connection-draft gave
RECOMMENDED values for (initial) window-sizes and max-packet-sizes for
different channel types since I believe throughput performance (on high
speed links) can vary some depending on client's and server's "mix" of
values. This is of course quite a speculative thing to recommend, however,
the usual implementation would be ontop of the secsh-transport ontop of
TCP. Speed of the link is of course a factor, but that's why it's called
INITIAL window size I guess, it's probably not constant...

One other thing which could be fun to standardize is the ssh-dss
key-formats since it is in everybody's interest(?) to be able to use keys
inbetween implementations (I know this is kind of an implementation issue,
but interoperability-wise it's a nice thing to standardize since most
implementations will probably use "ssh-dss" keys primarily, at least to
start with, or in a "basic" configuration).

Of course there is also the sftp file-transfer protocol which I gather
that Tatu(?) is writing up a draft on. If sftp is to be standardized,
could there be something that could be improved in the process?

Just my $.02...

Cheers,

/Mats

---

From: [email-masked] (Niels M�ller)
Date: 27 Jul 2000 17:33:16 +0200

> references to the SSHv1 agent protocol.

When talking about agent forwarding, one thing that I really would
like to see, is to add the final host (and service) to the data being
signed, and perhaps also some more information about the forwarding
path. The goal for such changes is to let the machine hosting the
agent cooperate with the target machine, to make sure that the
forwarding path does not pass through untrusted machines.

One should also note that the details of agent forwarding is deeply
intertwined with publickey userauth protocol. Improvements to the
forwarding mechanism will likely require a new "publickey-2" or
"publickey-forwarded" userauth mechanism.

(I haven't read any official documentation of the agent protocol, only
a description from someone who reverse engineered it).

/Niels

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Thu, 27 Jul 2000 15:06:05 -0600

> could there be something that could be improved in the process?

I think both of these issues are very important.

I would be very interested in discussing how to move forward
on both these issues - either during the meeting or during
some informal BOF Tuesday or Wednesday evening.

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 31 Jul 2000 18:52:53 +0200

> 	draft-ietf-secsh-connect-07.txt

I have reread the first two documents, and tried to recall problems
and ambiguities that I have encountered, or remember from the list.
Sections are marked as "minor" or "important".

I hope to get to the other two documents later.

Comments on the protocol drafts. 2000-07-31

: 3.1.  Host Keys
: 
: Each server host MUST have a host key.  Hosts MAY have multiple host
: keys using multiple different algorithms.  Multiple hosts MAY share the
: same host key. Every host MUST have at least one key using each REQUIRED
: public key algorithm (currently DSS [FIPS-186]).

(minor) In some situations, it is desirable to authenticate the host
using some secret shared between the host and a particular user.

: 3.6.  Localization and Character Set Support
: 
: ...
: 
: The client and server user names are inherently constrained by what the
: server is prepared to accept.  They might, however, occasionally be
: displayed in logs, reports, etc.  They MUST be encoded using ISO 10646
: UTF-8, but other encodings may be required in some cases.  It is up to
: the server to decide how to map user names to accepted user names.
: Straight bit-wise binary comparison is RECOMMENDED.

(important, but not urgent) This is too sloppy. Implementations should
be required to respect unicode character equivalence. Say I have an
account on a system that allows non-ascii characters in user names.
Assume I'm known to the system under the name "möller", which has at
least two different but equivalent representations in unicode (and
therefore also in utf-8).

As a user, I usually have no control over which of the representations
my local system and software uses, and if I have to configure my local
system to use the same (most likely undocumented) conventions as the
remote system, I lose. There may be some option to choose between
utf-8 and iso-8859-x, but I've never seen any user-level options for
choosing between different canonicalization conventions for utf-8.

A simple way to solve the problem is to require a particular
unicode/utf-8 canonicalization when usernames are sent across the
wire. I expect the WG for internationilized domain names to have
similar considerations.

: 4.1.  Encoding of Network Addresses
: 
: Network addresses are encoded as strings. DNS names MUST NOT be used, as
: DNS is an insecure protocol.

(important) DNS names should not be ruled out. For instance, when
setting up a TCP/IP tunnel, it might be useful (and perhaps even
increase security) to pass a dns name and let the server resolve it to
an IP-address.

So I would prefer if support for DNS names was optional rather than
disallowed.

: If an address contains a colon (':', ascii 58), it is interpreted as an
: IPv6 address. The encoding of IPv6 addresses is described in [RFC-1884].
: IPv4 addresses are expressed in the standard dot-separated decimal
: format (e.g. 127.0.0.1).

"dot-separated decimal" is too vague. It will be interpreted as
"anything that inet_addr() or inet_aton() accepts", which is not
standardized. I would propose something like this:

1. If an address contains a ':' character, it is interpreted as an
   IPv6 address (it seems unnecessary to allow the shorthand ::-forms,
   but that's a minor point).

2. Otherwise, view it as a sequence of components separated by dots.
   There must be at least one component, and no empty ones (and no
   leading no trailing dots. Or do we want to allow a trailing dot?).

3. If the rightmost component starts with a decimal digit, the address
   is interpreted as an IPv4 address, and it must consist of exactly 4
   components, each a number in the range 0-255, with no redundant
   leading zeroes.

4. Finally, if the rightmost, final component starts with a non-digit,
   the address is a symbolic DNS name, to be resolved to a numeric
   address when needed. If the name does not include a trailing dot,
   the systems DNS search path may be used.

: 3.3.1.  Old Client, New Server
: 
: Server implementations MAY support a configurable "compatibility" flag
: that enables compatibility with old versions.  When this flag is on, the
: server SHOULD identify its protocol version as "1.99".  Clients using
: protocol 2.0 MUST be able to identify this as identical to "2.0".  In
: this mode the server SHOULD NOT send carriage return character (ascii
: 13) after the version identification string.

(minor) Clients have been observed to *send* the protocol version
number "1.99". I can't see any reason for this; if there is one, it
should be mentioned here.

: 4.1.  Maximum Packet Length
: 
: All implementations MUST be able to process packets with uncompressed
: payload length of 32768 bytes or less and total packet size of 35000
: bytes or less (including length, padding length, payload, padding, and
: MAC).  Implementations SHOULD support longer packets, where they might
: be needed e.g. if an implementation wants to send a very large number of
: certificates.  Such packets MAY be sent if the version string indicates
: that the other party is able to process them.  However, implementations
: SHOULD check that the packet length is reasonable for the implementation
: to avoid denial-of-service and/or buffer overflow attacks.

(minor) Is there any rationale for the choice of the fudge factor
35000 - 32768? E.g. I have tried to look for the worst case expansion
when compressing a packet with zlib, but I haven't found any precise
numbers (the zlib docs says that the worst case for an _entire_ file
is 12 bytes + 0.1%, but it's not clear to my how to apply that to
individual blocks compressed with partial (Z_SYNC_FLUSH) syncing).

: 4.3.  Encryption

  ...
  
: The "arcfour" is the Arcfour stream cipher with 128 bit keys.  The
: Arcfour cipher is believed to be compatible with the RC4 cipher
: [Schneier]. RC4 is a registered trademark of RSA Data Security Inc.

(minor) I have heard cryptographers say that the first few bytes of
the arcfour keystream are weak (correlated to the first bytes of the
key or somesuch), and that one should always throw away the first few
10-100 bytes output by arcfour. Is that something that should be done
when using arcfour for ssh?

: 4.6.  Public Key Algorithms
: 
: This protocol has been designed to be able to operate with almost any
: public key format, encoding, and algorithm (signature and/or
: encryption).
: 
: There are several aspects that define a public key type:
: 
: o  Key format: how is the key encoded and how are certificates
:    represented.  The key blobs in this protocol MAY contain certificates
:    in addition to keys.
: 
: o  Signature and/or encryption algorithms.  Some key types may not
:    support both signing and encryption.  Key usage may also be
:    restricted by policy statements in e.g. certificates.  In this case,
:    different key types SHOULD be defined for the different policy
:    alternatives.
: 
: o  Encoding of signatures and/or encrypted data. This includes but is
:    not limited to padding, byte order, and data formats.

(important) The way I want to read this, there is a unique mapping
from key type to triples <key format, algorithm (including policy),
signature format>. I.e. when I advertise a key type, I *know* which
algorithms I have to support in order to live up to my advertising.
However, that's not the case for the defined key types,

: The following public key and/or certificate formats are currently
: defined:
: 
: ssh-dss              REQUIRED     sign      Simple DSS
: x509v3               RECOMMENDED  sign      X.509 certificates
: spki                 OPTIONAL     sign      SPKI certificates
: pgp                  OPTIONAL     sign      OpenPGP certificates

Say that a server has a dss hostkey, that it can offer as either a
ssh-dss key or as a x509 certificate chain. I'm running a client
that supports x509 (but only the most common rsa-based certificates)
and ssh-dss. If both programs lists x509 as their preferred public key
algorithm, it will be chosen, but communication will fail, even though
there is a ssh-dss hostkey that both parties can deal with.

I don't know the right way to solve this. Perhaps one needs to define
more keytypes, x509v3-dsa (implementation can deal with both rsa and
dsa) and spki-rsa. Here, rsa is the usual algorithm for use with x509,
while dsa is the usual one for spki.

This is mostly a problem for hostkeys, where communication fails when
the client can't deal with the hostkey. For user authentication, the
client can just try another key or key type.

: The resulting signature is encoded as:
: 
:   uint32    length
:   string    "ssh-dss"
:   string    dss_signature_blob

The redundant length fields in this and other representations has
already been discussed on the list. For the record, I would prefer
that they are removed.

: 5.1.  Algorithm Negotiation

: ... Each side MAY guess which algorithm the other side is using,
: and MAY send an initial key exchange packet according to the algorithm
: if appropriate for the preferred method.  If all algorithms were guessed
                                               ^^^
: right, the optimistically sent packet MUST be handled as the first key
: exchange packet. ...

(important) I feel the description of the "guessing" mechanism is too
vague. In particular, the meaning of "all" seems unclear.

: Key exchange begins by each side sending the following packet:
: 
:   byte      SSH_MSG_KEXINIT
:   byte[16]  cookie (random bytes)
:   string    kex_algorithms
:   string    server_host_key_algorithms

...

: The first algorithm in each list MUST be the preferred (guessed)
: algorithm.  Each string MUST contain at least one algorithm name.
: 
:     cookie
: 	The cookie MUST be a random value generated by the sender.  Its
: 	purpose is to make it impossible for either side to fully
: 	determine the keys and the session identifier.
: 
:     kex_algorithms
: 	Key exchange algorithms were defined above.  The first algorithm
: 	MUST be the preferred (and guessed) algorithm.  If both sides make
: 	the same guess, that algorithm MUST used.  Otherwise, the
: 	following algorithm MUST be used to choose a key exchange method:
: 	iterate over client's kex algorithms, one at a time.  Choose the
: 	first algorithm that satisfies the following conditions:

This seems inadequate. Consider the preference lists (where "foo"
stands for some key exchange method that requires an
encryption-capable host key):

  Server:
    kex_algorithms:             "foo,diffie-hellman-group1-sha1"
    server_host_key_algorithms: "ssh-dss,rsa-encrypt"

  Client:
    kex_algorithms              "foo,diffie-hellman-group1-sha1"
    server_host_key_algorithms: "ssh-dss,elgamal-encrypt"
    
Here, the "guess" foo is correct, but it will cause communication to
fail. Both parties preferences are reasonable, and they do have enough
in common that they ought to figure out that they need to use
diffie-hellman and ssh-dss.

:     first_kex_packet_follows
: 	Indicates whether a guessed key exchange packet follows.  If a
: 	guessed packet will be sent, this MUST be true.  If no guessed
: 	packet will be sent, this MUST be false.
: 
: 	After receiving the SSH_MSG_KEXINIT packet from the other side,
: 	each party will know whether their guess was right.  If the other
: 	party's guess was wrong, and this field was true, the next packet
: 	MUST be silently ignored, and both sides MUST then act as
: 	determined by the negotiated key exchange method.  If the guess
: 	was right, key exchange MUST continue using the guessed packet.

It needs to be clearly defined what it means that the guess was right.
I can think of several interpretations:

1. The first element of the server's kex_algorithms list equals the
   first element of the client's kex_algorithms list. This has the
   problem described above, and additional problems if the
   first_kex_packet feature is used, and the contents of that packet
   depends in any way on the host key algorithm.

2. The first elements of the server's kex_algorithms and
   server_host_key_algorithms lists equal the respective first
   elements of the client's lists. This seems more reasonable, but it
   still needs some extra conditions to deal with the example above.

3. The first elements of "all" the server's lists equal the respective
   first elements of the client's list. This is what the first
   paragraph says, but it seems like a unneccessarily strict
   criterion. I don't see much use to have the guessing mechanism
   depend on a correct guess for the bulk encryption algorithms, and
   even less use of it depending on a correct guess for the
   compression algorithms.

4. Interpret "all" algorithms to mean the kex_algorithms,
   server_host_key_algorithms, encryption_algorithms and
   mac_algorithms (but not compression_algorithms or languages).

: 5.2.  Output from Key Exchange
: 
: The key exchange produces two values: a shared secret K, and an exchange
: hash H.  Encryption and authentication keys are derived from these. The
: exchange hash H from the first key exchange is additionally used as the
: session identifier, which is a unique identifier for this connection.

(minor) I would like a line or two specifying whether or not the
exchange hash should be treated as secret information (when designing
and analysing user authentication mechanisms, it helps to be able to
assume one or the other).

: If the key length in longer than the output of the HASH, the key is
: extended by computing HASH of the concatenation of K and H and the
: entire key so far, and appending the resulting bytes (as many as HASH
: generates) to the key. This process is repeated until enough key
: material is available; the key is taken from the beginning of this
: value. In other words,
: 
:   K1 = HASH(K || H || X || session_id)   (X is e.g. "A")
:   K2 = HASH(K || H || K1)
:   K3 = HASH(K || H || K1 || K2)
:   ...
:   key = K1 || K2 || K3 || ...

(minor) As was pointed out on the list and coderpunks recently, this
key stretching mechanism loses entropy if the amount of entropy that
enters the system (in the form of K) is larger than the internal state
of HASH.

: 8.  Service Request
: 
: After the key exchange, the client requests a service. The service is
: identified by a name. The format of names and procedures for defining
: new names are defined in [SSH-ARCH].
: 
: Currently, the following names have been reserved:
: 
:   ssh-userauth
:   ssh-connection
: 
: Similar local naming policy is applied to the service names that is
: applied to the algorithm names; a local service should use the
: servicename@domain syntax.
:   byte      SSH_MSG_SERVICE_REQUEST
:   string    service name
: 
: If the server rejects the service request, it SHOULD send an appropriate
: SSH_MSG_DISCONNECT message and MUST disconnect.
: 
: When the service starts, it may have access to the session identifier
: generated during the key exchange.
: 
: If the server supports the service (and permits the client to use it),
: it MUST respond with
: 
:   byte      SSH_MSG_SERVICE_ACCEPT
:   string    service name

(minor) The service name part of this message seems redundant. It
would make sense (but still be redundant) if the client were expected
to send more than one SSH_MSG_SERVICE_REQUEST, which the server
responded to in turn (similar to the handling of
SSH_MSG_USERAUTH_REQUEST messages). But the spec requires the server
to reply with a SSH_MSG_SERVICE_ACCEPT at most once, and never give
the client a second chance if a service request is rejected.

/Niels