ietf-smtp
[Top] [All Lists]

Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

2001-07-27 12:33:55

        I have a difficult time understanding why SMTP client authors
thought it was acceptable to send SSL 2.0 Hello messages.  Maybe they just
blindly linked in SSL libraries without telling them what protocol
version to use?

Or they chose a pragmatic approach.  Some alleged 'STARTTLS' servers
only support SSL 3.0.  These are clearly broken, but making clients
backwards compatible with them still looks like a good idea.

it looks like a good idea IF it doesn't keep them from being
compatible with servers that conform to the standard.

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

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?

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.

Keith

<Prev in Thread] Current Thread [Next in Thread>