Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall

On Fri, Mar 26, 1999 at 09:43:26AM -0800, Scott Roberts wrote:

> The RFC for STARTTLS has a section for dealing with the middleman attack
> where the client should keep track of each server's TLS and remember the
> last time it was advertised. If a server stops advertising STARTTLS due to
> an invalid certificate or invalid configuration it could lead to false
> security issues and alerts when the problem was just a bad certificate that
> caused it to stop advertising the STARTTLS during the EHLO.

The "454 TLS not available due to temporary reason" answer to STARTTLS
could just as well indicate an MITM attack.  If the server is
misconfigured, it is very unlikely that waiting after the 454 response
will fix the problem (how often do people change their mail server's
configuration?) -- similarly, an incorrect "RCPT TO:" typically will
not generate "451 User does not yet exist" :-)

>     [...] The server will return a '454 TLS not available due to temporary
> reason' to any client that issues the STARTTLS command and fails.  If we do
> not advertise STARTTLS when there is ANY problem with the certificate or
> configuration than why have this error code?

"Temporary reasons" for unavailability of TLS could have several
reasons: E.g., after a reboot the server needs a password to decrypt
its key; or a decrypting smart card was just removed from the
interface because a new one with a new key is to be inserted.
A configuration mistake _might_ be a good reason, but only for limited
time (namely, while someone is working on the configuration: E.g., an
old certificate and key have just been deleted, but the new one is not
yet installed), not for more than, say, one day at most.
I think this proposal makes sense:

>> As I see it the real question is whether the mail can be sent within a
>> reasonable amount of time. If a server has had a working TLS
>> configuration that doesn't work just now then it should advertise
>> STARTTLS but if it has never been configured then it shouldn't. Five
>> days seems to be a common queue return time and so I suggest that if a
>> valid configuration has not existed in the last five days then it can be
>> deemed to have never existed.

This time-out should be configurable, but three days (one weekend) or
five days are probably a reasonable default.