Re: draft-hoffman-rfc2487bis-03.txt

[Lutz Jaenicke <Lutz.Jaenicke@xxxxxxxxxxxxxxxxx>]

On Thu, Aug 24, 2000 at 07:37:56AM -0700, Eric Rescorla wrote:
> > > > A server which does not have a certificate installed and which does not
> > > > support any anonymous ciphers SHOULD NOT advertise the STARTTLS keyword
> > > > as it is not currently able to negotiate the use of TLS.
> > 
> > > It's an case which implementors commonly get wrong.
> > 
> > Further, it's also an area where past SMTP proxy servers have made mistakes.
> > The proxy servers attempt to validate the SMTP commands as a
> > man-in-the-middle, passing through the STARTTLS option knowing full well
> > that they won't allow for TLS negotiation anyway. In one particular case,
> > the proxy server responded "250 OK" to the STARTTLS command (and, in fact,
> > it responded that way to _any_ unrecognized command) leading to a serious
> > communications breakdown as the client was starting to negotiate TLS while
> > the server was happily awaiting its next plain-text command.
> As you suggest, I'd be happy to see a blanket statement that if you're
> not prepared to negotiate TLS you shouldn't advertise STARTTLS.
> 
> The point I was trying to make is that there are all sorts of ways
> to not be actually ready to negotiate TLS that are no more stupid
> than not having a certificate. For instance not negotiating
> any cipher suites or having a certificate that doesn't match
> your cipher suite or whatever. (I definitely see this one a lot)
> I don't see the point of specially mentioning this one.

Hmm. I think I/we do need some clarification. Section 4 states:
    The STARTTLS keyword is used to tell the SMTP client that the SMTP
    server is currently able to negotiate the use of TLS. It takes no
    parameters.
Section 5 however allows
    454 TLS not available due to temporary reason

So actually, section 5 implicitly allows the server to step back from its
STARTTLS offer.
Wo what does it mean? When TLS is not available for a temporary reason, why
did the server first offer STARTTLS, as it obviously is not able to negotiate
the use of TLS. Or does it mean: sending the 454 reply already is part of
the "negotiation" and negotiation!=TLS-handshake.

A server not having a certificate suitable for its cipher suite or not having
a certificate at all (leaving out the anonymous case here) will not be able to
complete the TLS handshake.
Hence it has the choice to either
a) not advertise STARTTLS in the first place
b) advertise STARTTLS but then send the 454 response when actually trying to
   start the TLS handshake.
Alternative b) makes sense to me, if the administrator actually wants to
use STARTTLS but has made some configuration error and the server software
notices this error.
I think this is more consistant than alternative a) which would ignore the
intention of the administrator by simply not advertising STARTTLS.

Of course, when the admin never checks his setup, the 454 response will stay
for an unlimited amount of time.

The server in any case should not send the 220 Ready to start TLS response
if it cannot fulfill the requirements for a successfull TLS handshake.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke@xxxxxxxxxxxxxxxxx
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153