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

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

pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann) writes:

> nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?q?M=F6ller?=) writes:
> 
> >And no security advantage? The general assertion that there's no security
> >advantage is false. As always, it's a tradeoff that depends on lots of
> >circumstances.
> 
> That's basically just creating an artificial reason to justify it, rather than
> any real supporting argument.

One counter example should be enough to falsify a general assertion.
So some better arguments than the genereral assertion are needed for
discouraging the feature. Thanks for providing some.

> >1. The end nodes have constrained cpu capacity.
> 
> In that case why would you want a lightweight cipher in only one direction
> rather than both?

Because one believes that the heavier cipher is more secure, and one
can afford to use it in the low datarate direction.

> >I don't buy this at all. As for interoperability problems, it's true that
> >it's a rarely used (and likely not well tested) feature. 
> 
> It's not just rarely used, does anything use it? [...]

Now we're talking. This looks like a valid argument for removing the
feature.

> and using asymmetric algorithm choices was never even considered
> because of the danger of interop problems once it was deployed.

Out of curiosity, which ciphers did you support at all? With only one
or both of aes and des3 to choose from, assymetric choices doesn't
make much sense.

If we strike out the second MUST in

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

and an implementation chooses to not implement that, exactly what does
that mean? Will the implementation do algorithm selection as defined
in the spec, and then disconnect of it ends up with assymmetric
choices?

Or will it enforce that the *input* to the selection processing is
symmetric, i.e. that in the KEXINIT message,

  encryption_algorithms_client_to_server
     == encryption_algorithms_server_to_client
  
  mac_algorithms_client_to_server
     == mac_algorithms_server_to_client

(I think that's a better way of doing it). Then, what about
compression? To me, it makes sense to be able to choose compression in
only one direction, should that possibility be discouraged as well?

The details must be spelled out. If we really want to get rid of this
possibility, the cleanest and least confusing way of doing it would be
to define protocol version 2.1 with a changed KEXINIT format,

  byte      SSH_MSG_KEXINIT
  byte[16]  cookie (random bytes)
  string    kex_algorithms
  string    server_host_key_algorithms
  string    encryption_algorithms
  string    mac_algorithms
  string    compression_algorithms_client_to_server
  string    compression_algorithms_server_to_client
  string    languages_client_to_server
  string    languages_server_to_client
  boolean   first_kex_packet_follows
  uint32    0 (reserved for future extension)

but we have to get the 2.0 spec published first (and there are a bunch
of other details that should be fixed when we bump the version number).

I'm always confused when a spec allows flexibility which, for good or
bad and perhaps undocumented reasons, noone implements. (Last time I
was fooled in this way by an RFC was RFC1035 and the DNS QDCOUNT.
Noone supports QDCOUNT != 1, and there seems to be some reasonable
arguments for that. But since it's still allowed by the spec, it's
something that has been an annoying surprise to everyone that has
written a DNS client the last 15 years).

Regards,
/Niels