User interface, security, and "simplicity"

[David Wagner]

In article <20080506010850.GC15920 at hn305c2n2.ms.com> you write:
>On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote:
>> I believe that those who supply security products have a responsibility
>> to consider the knowledge, experience, and tendencies of their likely
>> users to the greatest extent to which they're able, and supply products
>> which will function properly _as users are likely to apply them_.
>
>The TLS support in Postfix tries to behave sensibly with "easy" setings.
>
>    - Cipher list selection is indirect, via grades: "export", "low",
>    "medium" and "high". The actual ciphers for each grade are buried
>    in parameters users are advised to not mess with.
>
>    - The cipher grade for opportunistic TLS is "export", but you single
>    out a destination for mandatory TLS, the grade rises to "medium".
>
[..]
>
>    - With the upcoming EECDH support, users don't choose curves
>    directly, they again choose a security grade, and the correspnding
>    curves are configurable via parameters they are not expected to
>    ever look at or modify.

This struck me as poor design, not good design.  Asking the user to
make these kinds of choices seems like the kind of thing that only a
cryptographer could consider sensible.  In this day and age, software
should not be asking users to choose ciphers.  Rather, the software
should just pick a sensible high-grade security level (e.g., AES-128,
RSA-1024 or RSA-2048) and go with that, and avoid bothering the user.
Why even offer "low" as an option?  (And this "export" business sounds
like a throwback to a decade ago; why is that still there?)

Good crypto is cheap.  Asking a user is expensive and risky.

>So I think there should be a broad design bias towards *implicit* correct
>behaviour in all system features, with rope available for advanced users
>to *explicitly* craft more complex use-cases. Once you have that, practical
>security is not too difficult.

Amen.  I know of quite a few software packages that could use more of
that philosophy.

>The same is true in the source code, unsafe practices are avoided
>globally, (e.g. both strcpy() and strncpy() are absent together with fixed
>size automatic buffers) rather than used with care locally. I won't bore
>you with all the implementation safety "habits", but there are many.

It's too bad that today such elementary practices are something to brag
about.  Perhaps one day we'll be lucky enough that the answer to these
questions becomes more like "of course we use safe programming practices;
what kind of incompetent amateurs do you take us for?".

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com