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