[cryptography] preventing protocol failings

Andy Steingruebl andy at steingruebl.com
Tue Jul 12 18:36:05 EDT 2011


On Tue, Jul 12, 2011 at 2:24 PM, Zooko O'Whielacronx <zooko at zooko.com> wrote:
>
> When systems come with good usability properties in the key management
> (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see
> this pattern. People are willing to use secure tools that have a good
> usable interface. Compare HTTPS-vs-HTTP to SSH-vs-telnet (this
> observation is also due to Ian Grigg).

I reject the SSH key management example though.  Especially if you've
ever maintained a large number/variety of unix servers running SSH,
where hardware failures, machine upgrades, etc. lead to frequent SSH
key churn.  In those cases the only solutions are:

1. Automate key distribution to things like the /etc/known_hosts file
via means that aren't built into or supported by SSH itself really,
they are an adhoc add-on.
2. Go to insane pains to ensure that keys don't ever change. Quite
tricky when you're trying to automate OS installs, etc.
3. Use keys-in-DNS for this, which defaults back to something quite
easy to attack.
4. Give up. Accept all keys without fail and just assume you're not
getting owned.

In practice unskilled sysadmins in large environments go with #4 most
of the time, and you're right back to where you started... you can't
defend against active attackers.

- Andy



More information about the cryptography mailing list