Re: draft-hoffman-rfc2487bis-03.txt

[Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Aug 17, 2000 at 03:43:21PM +0200, Lutz Jaenicke wrote:

> [Section 5]:
>    After receiving a 220 response to a STARTTLS command, the client
>    SHOULD start the TLS negotiation before giving any other SMTP
>    commands.
> 
> I would prefer MUST here instead of SHOULD.

So would I, and I said so one year ago when the previous revision of
the draft was being discussed on this mailing list (or possibly on
ietf-tls).  Paul commented that the client should have the possibility
to send a clear "QUIT" command instead of starting a handshake.

I don't believe that there's any implementation that can handle this
(although it should be not too difficult to patch Postfix-TLS
accordingly since you're using BIO pairs :-), and I don't think that
it makes sense to require servers to be able to handle anything other
than a TLS handshake after the STARTTLS.   Among other things, this
requires us to assume that the ASCII representation of "QUIT" (and of
any other SMTP command since the specification does not state that
only "QUIT" is allowed at this stage) will never coincide with the
first bytes of a valid TLS handshake message.  While this may be the
case, it is just a coincidence and does not follow from the design
goals of the SMTP and TLS protocols.

If, after having issued the STARTTLS command, the client finds out
that some failure prevents it from actually starting a TLS handshake,
then it should just abort the connection.


Another issue that IMO should be discussed in the draft, but isn't,
is backwards compatibility.  While specifying SSL 2.0 or SSL 3.0
connections is obviously out of the scope of the document, there
should be something on backwards compatible Client Hello messages,
i.e. Client Hellos with client_version of TLS 1.0 (or later)
but in the SSL 2.0 record format or in an SSL 3.0 record.
It's not quite clear to me if clients that use those backwards
compatible formats (and most, or even all, existing implementions do
this) violate the specification in draft-hoffman-rfc2487bis-03.txt.
If it's legal, then we have a problem because nothing in
draft-hoffman-rfc2487bis-03.txt requires servers to be able
to handle such Client Hello messages.

I think the specification should state that servers MUST be able
to understand backwards compatible Client Hello messages (provided
that client_version is TLS 1.0 or later), and that clients MAY
use backwards compatbile Client Hellos messages.  Of course neither
clients or servers can be required to actually offer the full
protocols because the specification is just about TLS.



-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036