RE: Interop problem with SMTP STARTTLS and Cisco PIX firewall

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

I suspect some words in the TLS draft that provide guidance would be
appropriate here.  Declaring an implementation as being "not high quality"
due to a reasonable implementation decision and operator error seems
unreasonable.


Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties



-----Original Message-----
From: Michael Salmon [mailto:[email protected]]
Sent: Thursday, March 25, 1999 12:10 AM
To: [email protected]; [email protected]
Subject: Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall 


+----- On Wed, 24 Mar 1999 23:47:55 PST, "Scott Roberts" writes:
| In your email below you state that the primary problems are that the Cisco
| PIX is not RFC compliant and that Exchange 5.5 advertises STARTTLS even if
| no certificate is configured.  I do not have PIX so I will not comment
| regarding the problems it might have. I would like to comment on your
| opinion that a server that has a problem with its certificate should not
| advertise STARTTLS.
| 
| If the SMTP Server is not configured with a certificate, or it has
expired,
| or it is using an invalid certificate the TLS Client will STILL fail
during
| the TLS negotiation. If the SMTP Server did not advertise STARTTLS, due to
| an invalid or absence of a certificate, the TLS Client might return the
| message to the sender stating that the server does not support TLS even
| though the server was configured to do so. If the SMTP Server, with no
| certificate, advertised STARTTLS the negotiation would fail but the TLS
| Client would be aware that the server supports TLS and attempt to send the
| message at a later time in hopes that the certificate issue will be
| resolved. The issue is not with the product itself but with our opinions
on
| what is expected by the SMTP server when there is an issue with the
| certificate and if it should advertise STARTTLS or not.

It seems to me that the right thing to do is only advertise STARTTLS if 
you plan to support it sometime in the near future i.e.:

" Make sure there is at least a mode where STARTTLS is not advertised.  A
quality implementation will only advertise STARTTLS if a valid server cert
is correctly configured. "

Waiting for mail to time out in a queue isn't particularly useful to 
anyone.

/Michael