RE: AEAD in ssh

denis bider <[email protected]> writes:

>It seems to me the only way you have a computing resource problem is if your
>customers' stinginess increases in tandem with miniaturization. For example,
>maybe a number of years ago your customers were willing to pay $10 per
>gadget. Now, perhaps they're willing to pay only $1, while keeping
>performance the same. Is that the trend you see?

There are two things I see, the first is as you describe, the industry is
driven by cost, not having the latest flashy gadgets.  Ten years ago, the
state of the art was a Cortex M3.  Today, it's a Cortex M3.  In ten years
time, it'll be a Cortex M3 (or perhaps an M0++ or whatever it'll be called
then, since vendors have been pushing the cheaper M's because that's where the
demand is).

(Alongside Cortex M's there's also a bunch of Power stuff which has some
devices good for rough environments, alongside R-series ARMs).

The second is that in embedded, and I mean real embedded not cheap IoT junk
from China, the driver is reliability and long life and not fancy features.
You've got 10-20 year product lifecycles, so devices that once deployed need
to operate for 10-20 years without updates and upgrades every few months.  To
give a somewhat extreme example, there are companies that scour eBay for 1990s
x86 hardware to run compilers from the same era to do the translation of
source code into binary, because that's what was certified and they can't move
to anything else without going through the certification process again, which
involves more work and cost than staying with the current process.  This is
code that has requirements like no recursion, no dynamic memory allocation,
100% test coverage of all code paths (that leads to some interesting code),
and so on.  It's also stuff that's incredibly reliable, which is why the
constraints are so tight.

>it seems to me that the needs of this market segment might indeed be best
>served by some restricted subset of existing protocols, 

Yup.  Unfortunately standards groups seem to be going in the opposite
direction, adding more gratuitous bloat and complexity to every protocol in
sight.

>or a protocol designed specifically for that.

I can't really see that ever happening.  The people who design the thing have
as their target hardware platform a Powerpoint slide projector, not real-world
devices.

>I don't want your 10 cent implementation to constrain me in what I can
>provide to my users, however. Maybe you can't afford a fixed-bandwidth
>terminal session. However, it seems like an excellent fit to provide privacy
>for interactive administration of a server in a data center.

Sure, include all the fancy extras you need, but make it optional, and don't
change the base protocol, or put constraints on it that will make it a pain or
impossible to use on constrained devices.

Peter.