[Top] [All Lists]

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

2001-07-27 07:51:13

This is completely bogus.  The reason we have a TLS specification
is so people can get interoperability by implementing it.  If they 
instead implement some earlier specification that isn't TLS, they're
not meeting the requirements of the standard.  SMTP servers that claim 
to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN, 
full stop.

I agree that such servers are broken.  But clients may want to
tolerate them anyway, and it is easy for TLS-only servers to tolerate
clients tolerating such broken servers.

Servers can tolerate such clients if they wish.  But clients that send 
anything other than a TLS 1.0 Hello message shouldn't expect to 
interoperate with servers that assert STARTTLS.  The way the TLS
protocol is designed, the burden is on the client to send an appropriately
formatted Hello message.

The TLS protocol includes provisions for protocol version negotiation.

Yes, I understand.  It's the SSL 2.0 Hello messages that I'm concerned 
about, not SSL 3.0 Hello messages with a maximum version # >= 3.1.

And yes, this is really a bug in the TLS spec, and maybe that's where
it should be fixed.  

But given that SMTP STARTTLS has *never* supported anything less than
TLS 1.0 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?

I think it's quite reasonable to document the fact that lots of SMTP
clients have been shipped that send out SSL 2.0 Hello messages, and
that servers might want to support these messages (you could even
say RECOMMENDED) in addition to TLS 1.0 messages.  But in the future, 
clients should send TLS 1.0 Hello messages.

does it matter?  the current specification defines rules such that if you 
follow them, you should be able to interoperate.  what you're proposing 
to do is to change the rules so that servers that followed the old 
spec, might not interoperate with clients that follow the new spec.

This is true, but I seriously doubt that there are any servers that
would have such problems.  

I have limited faith in a WG's ability to enumerate all existing 
implementations, and I don't like the WG deciding that broken 
implementations are more deserving of compatibility with future
versions of the standard, than ones that followed the original spec.

As I said before, essentially all existing
STARTTLS clients are 'broken' in the sense that they use backwards
compatible Client Hello messages; so STARTTLS servers not supporting
backwards compatible Client Hello messages wouldn't be able to survive
in the wild.  


not necessarily true - it just means that people wouldn't use the
STARTTLS feature of the client.


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