Re: draft-hoffman-rfc2487bis-03.txt

[Lutz Jaenicke <Lutz.Jaenicke@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 30, 2000 at 10:10:41AM +0200, Bodo Moeller wrote:
> >> No.  This 454 is a reply that clients may see in response to STARTTLS
> >> when STARTTLS was not offered in the EHLO reply.
> 
> > My understanding is that a client should not use the STARTTLS command if
> > it was not offered. It may see a 5xx reply in that case.
> 
> The client *should* not use the STARTTLS command, but if it does
> anyway (e.g. because it is configured to always use STARTTLS when
> connecting to that host and thus the reply to the initial EHLO is not
> even parsed), why not use a reply that tells the client that the
> server does understand the STARTTLS command in principle, but cannot
> handle it at the moment?  As this reply is not cryptographically
> authenticated, it does not provide any security advantages whatsoever
> (assuming that plain TCP over plain IP is used), but it may be helpful
> for tracking down configuration problems.

It seems we are thinking the same thing, just expressing it in a different
way :-)

The client can send a STARTTLS whether it was announced or not. The client
then must be able to handle the answer of the server, which can be
2xx The server can initiate the TLS handshake (STARTTLS announced or not)
4xx The server can not initiate the TLS handshake as of now, maybe later.
5xx The server cannot initiate the TLS handshake, because it is not able to
    do it or does not want to do it.

Now it is up to the client to decide. For a 4/5xx answer, the client can
decide to continue without encryption. If encryption is obligatory, the
client will probably bounce the message for the 5xx answer, as it cannot
expect TLS to become available, or retry later for a 4xx answer when the
problem with the server has been solved. (That's what I might do, but this
decision is left to the client.)
This should hold whether STARTTLS was offered (or filtered out by an attacker)
or not, as the 2/4/5xx answer may have been altered on the way, too.

It should just be clear that the client MUST not send a STARTTLS if it
cannot initiate the TLS handshake itself at this time.

> (Also, if the server initially thinks that it can handle TLS, but
> initialization fails for some reason, this 454 response may make sense;
> or maybe just abort the connection.  There can always be unpredicted
> problems, such as someone removing the smart card that is responsible
> for private key operations, or the process running out of memory,
> or a power failure, or whatever.)

Yes. 

I a certain sense I discussed the use of MUST, SHOULD etc with respect to
the implementation. Of course the operator must be taken into account, too.
Any MTA server implementation will fullfill the "STARTTLS MUST only be offered
when the server is actually ready to initiate the TLS handshake" when I
additionally take into account, that the operator of the server must take
care of the correct installation and setup (otherwise it will not comply
to the standard). The implementation cannot take into account all possible
causes of failure (even though it probably SHOULD try its best to do so).

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