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

[Keith Moore <moore@xxxxxxxxxx>]

> [...]
> >>> 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.

Keith