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

[Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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
>>    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?

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
existed anywhere?


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