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

From: [email-masked] (Peter Gutmann)
Date: Sat, 15 Nov 2003 19:18:53 +1300

[email-masked] (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.  How many cases of this have you actually run
into so far?  How does the user determine what to use in which direction?  How
do they ensure that nothing sensitive gets sent over the less-secure channel?
How do they configure the software to do this?  For that matter, do they even
know that this capability exists?

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

>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?  I seem to remember at one
point screwing up the handshake code during testing so it somehow reported two
different algorithm choices, and getting back an error from whatever server I
was bouncing messages off at the time saying that the incoming cipher choice
didn't match the outgoing one, which doesn't inspire confidence.

In the constrained-CPU case, cryptlib is used in one of the (if not the) most
constrained implementations I know of (16-bit embedded CPU at around 10MHz, it
takes 15s just to do a 512-bit private-key op), and using asymmetric algorithm
choices was never even considered because of the danger of interop problems
once it was deployed.  I did talk about it with people looking at another
embedded use, but it was ruled out pretty much instantly (the phrase
"lightning rod for every implementation bug in every SSH implementation ever
created" came up during the discussion).  Any low-power CPU implementation is
probably going to be some embedded system, for which firmware updates will be
problematic.  If you're going to include a feature that's a lightning rod for
implementation quirks, the last place you want to put it is in a device where
it's either impossible or at least very difficult to change the code to work
around the quirks.

So I don't buy the argument that this is worth supporting, and in the few
situations where it might hypothetically be useful it's downright dangerous.
I agree with the original poster that its use should be discouraged.

Peter.

---

From: [email-masked] (Niels Möller)
Date: 15 Nov 2003 11:40:53 +0100

[email-masked] (Peter Gutmann) writes:

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

> In that case why would you want a lightweight cipher in only one direction

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

> 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

---

From: Markus Friedl <[email-masked]>
Date: Sat, 15 Nov 2003 17:13:06 +0100

> to define protocol version 2.1 with a changed KEXINIT format,

i don't think it makes sense to switch to a new protocol version
because of this minor issue.  it makes only sense if you don't have
to care about interoperability.