User interface, security, and "simplicity"
Victor.Duchovni at morganstanley.com
Tue May 6 15:52:51 EDT 2008
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote:
> > - 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.
They are not *asked* to make any cipher choices. The are able to make:
- no explicit choice, and get sensible default behaviour
- a high level choice ("secure verification" + "high grade cipher"
without having to spell out the gory details of what these mean.
- an exteremely detailed specification of all the details.
> In this day and age, software
> should not be asking users to choose ciphers.
The users in question are email administrators, not end users, and you
missed my point. They are not asked to choose ciphers, these are chosen
for them, and the default choice is even context dependent, so you get
sensible combinations of security properties:
- Opportunistic TLS allows SSLv2 and export ciphers
- Mandatory TLS, enforces SSLv3/TLSv1 and medium or high
> 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
This is what is done (using OpenSSL's "HIGH", "MEDIUM", ... selectors).
> 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?)
You don't know how TLS is used with SMTP. Most TLS is opportunistic and
plain text is used if TLS is absent. In such an environment insisting
on 128 bits is silly, even 40 bits is better than plain-text.
> Good crypto is cheap. Asking a user is expensive and risky.
Breaking interoperability by limiting cipher selection and causing mail
to queue is not cheap.
> >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?".
Practices are "culture" not "technology", and it is difficult to displace
existing cultures with new ones :-(
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography