Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall

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. I think we need
to add a section to the RFC stating when a server SHOULD,MUST, MUST NOTor
MAY advertise STARTTLS due to an  invalid configuration that would always
cause STARTTLS to fail. This is mostly covered in 'Section 5 - The STARTTLS
command'. 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?

Scott


>>RFC 2487
   A man-in-the-middle attack can be launched by deleting the "250
   STARTTLS" response from the server. This would cause the client not
   to try to start a TLS session. An SMTP client can protect against
   this attack by recording the fact that a particular SMTP server
   offers TLS during one session and generating an alarm if it does not
   appear in the EHLO response for a later session. The lack of TLS
   during a session SHOULD NOT result in the bouncing of email, although
   it could result in delayed processing.

-----Original Message-----
From: Michael Salmon <[email protected]>
To: [email protected] <[email protected]>; [email protected]
<[email protected]>
Date: Friday, March 26, 1999 12:02 AM
Subject: Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall


>+----- On Thu, 25 Mar 1999 14:40:48 PST, "Larry Osterman (Exchange)"
writes:
>| I think that Scott has a valid point (and not just because he works for
the
>| same people as I do, anyone who knows me knows I often disagree with
people
>| I work with)...
>|
>| There is a real issue here - it is totally reasonable to have a client
that
>| is configured to only talk to an SMTP server that supports STARTTLS, and
you
>| don't want the client to blindly fail when the server is CAPABLE of
>| supporting TLS but currently has a configuration error that causes it to
>| prevent TLS negotiation from succeeding.
>|
>| I actually think that the right thing to do is to advertise STARTTLS
(since
>| thats a server capability) and to fail the STARTTLS command with a
>| distinguished 4xx error (and of course the server should raise huge
alerts
>| and warnings).
>
>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.
>
>/Michael
>