On 2009-06-15 at 14:17 -0700, David Schwartz wrote:
> Phil Pennock wrote:
> > The approach of the Exim MTA to cryptography is simple -- don't
> > second-guess the SSL library developers when it comes to choosing which
> > algorithms/digests/etc to load, and provide a knob
> > ("tls_require_ciphers") for administrators to restrict what can be
> > loaded. The MTA developers do not want to be in the cryptoanalysis
> > game, deciding when digests are or are not safe to use and reason that
> > this is best handled by the SSL libraries which are maintained by people
> > who understand this stuff better.
>
> That just won't work. Cryptography is not a "drop in a library and mark a
> checkbox on your product" thing. It has to be properly integrated in an
> application with decisions made as to what the application actually needs,
> what threat models it faces, and so on.
While so true, nobody's even come up with a definition of which hostname
should be verified by an MTA when delivering to another MTA, so there's
no hostname verification, so the security model for TLS for MTA->MTA
communications is broken, independent of which software is used for the
MTA. So at *best*, there's opportunistic link encryption.
Mail client (MUA) -> Mail submission server (MSA, aka MTA on port 587)
is tolerably defined, but that's about it.
None of this is specific to this application.
So the only real verification is "trust path for the certificate, used
for this purpose, to a trusted CA with every step valid". *This* is
supposed to be bog-standard SSL/TLS usage.
> OpenSSL is a library that provides security services to applications, but it
> has no idea what those applications need, what threats they face, what
> security model they live in, and so on. You cannot simply accept the
> defaults and hope for the best. That might work, but to be reliable,
> somebody somewhere has to make sure it does in fact work.
Right. But what in this requires that the application know, or encode,
which particular digests are or are not currently considered safe?
Aside from the unfortunate reality of no hostname verification, the MTA
use-case is a standard profile and should accept "normal" algorithms in
real-world use by Certificate Authorities in the wild today.
You cannot simply take a bunch of common-sense stances and extrapolate
past "understand your security model" to "every application needs to be
maintained by cryptanalysts who keep track of which ciphers are
currently needed by or broken for operation of SSL/TLS". Not if there's
any real-world expectation that the applications all keep up and that a
crypto breakthrough can be fixed by configuration and recompiling the
SSL libraries, instead of recompiling each and every SSL application,
after waiting for code updates from those developers too.
-Phil
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
