Re: draft-hoffman-rfc2487bis-03.txt

[Lutz Jaenicke <Lutz.Jaenicke@xxxxxxxxxxxxxxxxx>]

On Tue, Aug 29, 2000 at 01:57:57PM -0700, RL 'Bob' Morgan wrote:
> 
> > 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.
> 
> A client that wants to protect itself against an active attacker deleting
> the STARTTLS in the EHLO from the server should go ahead and do STARTTLS
> anyway.

Agreed.

Ok, I will discuss an implementation to make clear how I understand the
STARTTLS negotiation. Actually, I will be discussing Postfix/TLS (in a
future version :-)
For those not familiar with Postfix (www.postfix.org, probably the readers of
this list are somewhat aware of the postfix MTA): Postfix consists of
several daemon processes, that are started on demand and that are initialized
when started. It is part of the security policy that the interdependency
between daemons is as small as possible. There is no "master" process that
is forked and so automatically distributes information to its children.

Whenever an incoming SMTP connection is accepted a new "smtpd" process is
started (or an idle one is reused). As of now, this means that all information
necessary to run the smtpd process has to be acquired at this time, and
this also includes the TLS data like keys, random seed etc. So at EHLO
time the server knows whether it can start TLS and hence can offer STARTTLS
(or may decide to not offer it).
In a future version, the TLS-layer/processing will be performed in a seperate
process, offering the advantage that the information is better encapsulated
for security reasons. It could also have performance advantages. Only a
small number of clients actually uses STARTTLS, so the TLS initialization
is often done in vein and should be delayed until really necessary.
* SMTP connection is opened
- Client sends EHLO
- Server is configured to use TLS, so STARTTLS is offered.
- Client sends STARTTLS
- Server now starts TLSserver process and notes, that for some reason
  whatsoever (certificate expired, no random number seeding) the configuration
  does not allow to successfully perform a TLS handshake [even though the
  administrator actually wanted TLS to be enabled].
  -> Server answers 454 TLS not available due to temporary reason
- Client decides whether to continue or not...

>From my understanding of RFC 2487 (and the latest draft) this behaviour
is conform with respect to the standard.
For the client side it is easier, as the client can wait with its decision
whether it wants to issue a STARTTLS command.

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