User interface, security, and "simplicity"

[Victor Duchovni]

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

    - The "secure" peer cert validation level compares the peer's cert to
    the nexthop domain (allowing a sub-domain match by default). Hostnames
    derived from MX lookups are of course subject to DNS MITM and are not
    trusted.  If you want to trust your DNS you can use "verify" instead.

    http://www.postfix.org/TLS_README.html#client_tls_limits
    http://www.postfix.org/TLS_README.html#client_tls_may
    http://www.postfix.org/TLS_README.html#client_tls_encrypt
    http://www.postfix.org/TLS_README.html#client_tls_verify
    http://www.postfix.org/TLS_README.html#client_tls_secure

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

If you don't botch your CAfile, it is rather easy to provision
secure-channel connections to a select set of high-value peers.

If you don't trust any CAs:

    http://www.postfix.org/TLS_README.html#client_tls_fingerprint

once you have a system designed in all its features to behave sensibly
by default (e.g. with an empty main.cf file), making security behave
sensibly by default is not that unnatural.

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.

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.

-- 
	Viktor.

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