On Fri, Jul 27, 2001 at 03:33:52PM -0400, Keith Moore wrote:
The successor of RFC 2487 with those backwards-compatibility-compatibility
requirements will actually be easier to implement than RFC 2487. Here's
some RFC 2487 fun:
After receiving a 220 response to a STARTTLS command, the client
SHOULD start the TLS negotiation before giving any other SMTP
I.e., when the server expects a Client Hello message (in whatever
format), it may receive an SMTP command in plain ASCII instead if the
client has decided that it does not want to use TLS after all.
because it's only a SHOULD and not a MUST.
I agree, that's a bug in the spec.
I bet that not only most clients are 'broken' (because they use
SSL 2.0 compatible Client Hello messages), but all servers are 'broken'
too because they cannot handle cleartext SMTP commands directly after
they have accepted STARTTLS.
This, too, should be changed. This time the change to the
specification will magically repair lots of broken servers at the risk
of turning some conforming clients into non-conforming ones.
even conforming clients need a good reason to violate a SHOULD.
how many good reasons to do this have been identified?
It is easy to make up a reason. E.g. the client TLS implementation
wants /dev/random-style randomness and some other process on the same
host has used up all the entropy, so instead of sending a Client Hello
the client falls back to cleartext.
These are two specification changes that will adjust the RFC to
reality. There's a minor chance that some previously conforming
implementations suddenly will stop to be conforming,
that's not the issue. the issue is whether implementations conforming
to the old specification will stop interoperating with those conforming
to the new specification.
I agree that we shouldn't worry about being non-interoperable with
nonexistent implementations. But I seriously question whether you
can determine that there aren't a significant number of such
implementations. I expect there would be a delay between deployment
of such implementations and use of the STARTTLS feature, so the
"would not survive in the wild" argument is, for me, unpersuasive.
Surely *someone* would have heard of such an implementation if it
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036