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

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

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