Re: draft-hoffman-rfc2487bis-03.txt

[Claus Assmann <ca+apps-tls@xxxxxxxxxxxx>]

On Thu, Aug 24, 2000, Lutz Jaenicke wrote:

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

This may happen because some part of the setup is done after the
initial greeting, esp. if it is expensive to do so. This will happen
in the current sendmail implementation if generating a temporary
RSA key will fail (yes, I know we could generate one beforehand
and reuse it a few times...).

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

The server should only offer STARTTLS if it "normally" can perform
the TLS handshake, i.e., all checks up to this point have been successful.
If later on something fails (e.g., actually creating the session context),
then the server should say so before starting the TLS handshake
and failing at that level.

> I think this is more consistant than alternative a) which would ignore the
> intention of the administrator by simply not advertising STARTTLS.

If there is a configuration error, then IMHO either
- the server shouldn't start at all
- log an error and continue but not offer STARTTLS
The main point here is to let the admin know that something is wrong.

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

And then it is up to the sender what to do...

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

Which brings me to the point of "broken" (non-interoperable)
implementations. Unless I missed it, I can't see a recommendation
in the draft what to do in that case, i.e., drop the connection.
Something to this extend should be added.