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

[Damien Miller <djm%mindrot.org@localhost>]

Jeffrey Hutzelman wrote:

> On Saturday, November 15, 2003 17:55:03 +0100 Niels Möller 
> <nisse%lysator.liu.se@localhost> wrote:
> 
> 
>>Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:
> 
> 
>>>the negotiated value SHOULD be the same in both directions.
>>
>>I think it's a lot better to say that the lists in the KEXINIT
>>message, i.e. the *input* to the negotiation, SHOULD be the same for
>>both directions.
> 
> 
> Actually, that was my interpretation of what was said during the working 
> group meeting.  It seems to me that requiring or recommending that the 
> foo_client_to_server and foo_server_to_client fields of the KEXINIT message 
> contain the same list is the only sane way to describe this requirement.

I don't agree.

It is reasonable for a server to be willing to accept compressed data,
but refuse to send it (decompression being generally less CPU intensive
than compression). I.e. comp_c_to_s "zlib, none", comp_s_to_c "none"

Likewise a server may be happy to encrypt data to clients with a less
secure, but faster cipher whilst requiring that clients send their
information (especially the auth transactions) with a stronger, slower
cipher. An extreme case would be the use of the "none" cipher in the
s->c direction (though OpenSSH doesn't support "none").

Bidirectional algorithms have been in the spec for years (without
complaint) and are supported by a number of implementations. Why is it
that these objections are always raised at the 11th hour?

I don't think the draft should be changed. Implementors who don't like
the idea of bidirectional algorithms are free to disallow them in their
implementation.

-d