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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:

> The proposal during the WG session was that we should add text so that
> for both algorithms and language tags,

Why language tags? I think assymmetric choices make a lot of sense:
For example, sending Swedish messages from server to client (because
that's the user's native and preferred language, but default language
or English (because these messags will end up in the server log, and
the sysadm doesn't read Swedish, or because the client doesn't
implement any localization for messages it sends to the server).

And furthermore, implementations that want to take the easy way can
just send an empty language list and ignore whatever is received, so
they gain no simplicity by the ban on assymmetric language lists.

And what about compression? Should support for assymetric choices for
compression be required?

> 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.

It makes no sense to say that implementations MUST go to the
trouble[1] of performing independent algorithm selection for both
directions, and then say that they are allowed, and even recommended,
to sometimes refuse to use the result. The point of discouraging
assymetric choices should be to make things simpler for the
implementations.

I'm still uneasy about this issue. I believe it is a *minor* trouble
to implement assymetric choices. But since I have to admit that I
don't implement any way for the user to configure assymmetric choices,
and therefore haven't tested it at all, I can agree that it's not an
essential feature.

I think I'd prefer to keep the feature, and perhaps add some text that
allows implementations to refuse to accept KEXINIT messages with
assymetric algorithm lists for encryption and authentication.
Something like

  The ciphers in each direction MUST run independently of each other,
  and implementations SHOULD/MAY allow independently choosing the
  algorithm for each direction (if multiple algorithms are allowed by
  local policy).

  Implementations MAY choose to not support independent algorithm
  choices for the two directions. In this case it MUST check that

    encryption_algorithms_client_to_server 
      == encryption_algorithms_server_to_client

  in all received SSH_MSG_KEXINIT messages. If the lists differ, the
  implementation MUST send a SSH_MSG_DISCONNECT message with reason
  code SSH_DISCONNECT_KEY_EXCHANGE_FAIL and a proper explanation.

  Implementations SHOULD send SSH_MSG_KEXINIT messages with

    encryption_algorithms_client_to_server 
      == encryption_algorithms_server_to_client

  unless they have been explicitly configured to behave differently.

and similarly for authentication methods, but *not* for language tags
or compression algorithms. The essence of this is to

  (i) make support for assymmetric choices an optional feature,

  (ii) to specify how the protocol should work if the feature is not
       implemented, and finally,

  (iii) say that implementations shouldn't use the feature unless
        there's a good reason to use it, for example "the user said
        so".

/Niels