On Wed, Oct 02, 2013 at 07:38:42PM -0400, micah wrote:
> I suppose there is no way to achieve some middle ground of doing
> opportunistic encryption, but for those who are only talking with bad
> protocols and ciphers (or clear-text) do a non-permanent failure with a
> message about their bad protocol so at least some admin eventually may
> see that information (perhaps when the user complains that their
> messages are slow to be delivered).
What would be the point? You accept plaintext mail, but reject
mail encrypted with algorithms vulnerable to a costly, but not
infeasible brute-force effort?
> > > smtpd_tls_eecdh_grade = ultra
> >
> > Perhaps, though if the NIST curves are "cooked", it is not clear
> > that 512 bits is better than 256, and if not, then 256 may well be
> > enough. Here you need new non-suspect curves, and none are described
> > in relevant RFCs or available in OpenSSL at this time.
>
> When you say 'Here you need new non-suspect curves' - do you mean with
> using eecdh ciphers in general? If there is suspicion that they are
> cooked, maybe these should be disabled?
I don't have anything substantive to say on the topic of the NIST
EC curves. All I know is that some people no longer trust them,
apparently not because they know the curves have backdoors, but
because they no longer trust the good faith of those who proposed
the curve parameters. The magic PRNG seed constants that generate
the "verifiably random" curve parameters remain a mystery. They
could be simply random in the first place, or the SHA-1 digests of
some (unpublished) inside joke, or the result of exhaustive
brute-force search for desirably weak curves (based on mathematical
results not known outside NSA).
This said, I also see a great deal of over-reaction, with bogus
rumours about deliberate weakening of AES-256 by NIST (false), or
deliberate sabotage of SHA3 (I am confident also false).
So it is far from clear whether:
- The NIST curves are cooked and should be avoided
- Prime EDH is weak as a result of NSA break-throughs and should
be avoided.
- RSA is weak as a result of NSA break-throughs and should be avoided.
...
So, when security matters, use the strongest crypto available, but
worry a lot more about end-point security, not the crypto. With SMTP,
I do nothing other than perhaps implement DNSSEC + DANE.
> >> What are some ways that we could improve the situation?
> >
> > You could disable SSLv3 in the SMTP client, and use only TLSv1,
> > TLSv1.1 or TLSv1.2.
>
> Do you mean in the MUA, or in the 'smtp' configurations in postfix? If
> the latter, what happens when you disable SSLv3 and connect to a remote
> MTA to make a delivery and they do not support anything but SSLv3?
In all SMTP clients, since SMTP servers almost universally support
TLSv1. There are exceedingly few servers that don't. You'd end
up sending in the clear to these. Disabling SSLv3 is not very
useful yet, the benefits only become real when TLS extensions sent
by the client allow servers to choose more secure parameters for
EECDH or EDH, which is not possible yet due to API and protocol
limitations. This said it is unlikely to cause any significant
problems.
> > Neither Postfix nor OpenSSL actually care about the size of the
> > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits,
> > and likely get away with it. See recent thread on Exim TLS interop.
> > YMMV, some clients may choke on 2048-bit EDH (though more typically
> > these limited implementations are in are browsers, ... not MTAs).
>
> Interesting, what interoperability problems are there here? If you set
> the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a
> client chokes on this? Does it fall back to clear text, or a non-EDH
> cipher, or does it cause a connection reset... or?
Some clients don't implement EDH for primes larger than some limit,
possibly as low as 1024 bits. Such issues are common in browsers,
and perhaps MUAs, but very uncommon in MTAs. When the TLS handshake
fails, the MTA behaviour is implementation dependent. Postfix (which
does not have such limits) retries with plaintext, unless constrained
by out-of-band policy (administrative or DANE).
--
Viktor.
