Re: additional core draft nits in need of WG attention.

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> If proof of possession of the derived keys was a design goal, the 
> protocol as it exists today already does not meet the goal, since there 
> is obviously _some_ case in which the requirement is not meant to apply 
> (otherwise it wouldn't be conditional!).  I would think that if this was 
> a goal, it would have been called out by an explicit pipeline-stall, in 
> the form of a pair of messages which behave like SSH_NEWKEYS (before you 
> can proceed, you MUST both send your message and receive your peer's).  
> Finally, note that in diffie-hellman-group1-sha1, the version and 
> algorithm negotation as well as the key exchange itself (together, the 
> equivalent of the TLS handshake) are authenticated by the signature at 
> the end of the key exchange.

Note that in practice, we do have proof of possession, since
in order to do anything, the client must successfully send
a service request and the server must successfully respond.

(There really isn't much that is useful that you can do
with the transport layer alone.)

The only case where you could run into trouble is if the
client assumes it's service request was going to succeed
and sent the first userauth packet at the same time.

I would claim that doing this would violate at least the
spirit of the protocol if not the letter.  And if someone
ever introduced a different service (which could easily be
done in an extension draft or even using a proprietary
@dns.domain extension) such a client would fail to interoperate
or to fail in a gracefully manner.

- Joseph