Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall

Chris Newman <[email protected]> Fri, 26 Mar 1999 16:34:43 -0800 (PST)
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
On Fri, 26 Mar 1999, 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.

If a site I communicate with lets their cert expire, that certainly
merits a security alarm in my book.  The nature of the security alarm
might be slightly misleading in this case, but having a security alarm is
a good thing.

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

Agreed.

> 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?

That error code is useful when the server is too busy to afford PKI
operations.  Also for any other cert-related failure which doesn't require
human intervention to correct.

		- Chris