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

[Keith Moore <moore@xxxxxxxxxx>]

> >>> Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
> 
> >>       Clients MAY use backwards compatible SSL Client Hello message
> >>       formats.  However, except for SSL session resumption, Client
> >>       Hello messages MUST be suitable for negotiating TLS 1.0 or later
> >>       (i.e. the version field of SSL 2.0 compatible Client Hello
> >>       messages or the client_version field of SSL 3.0 compatible Client
> >>       Hello messages must be at least 3.1).
> >> 
> >>       Servers MUST be able to understand backwards compatible SSL
> >>       Client Hello messages, provided that the client indicates that
> >>       it supports TLS 1.0 or later.
> >> 
> >>       Note that neither clients nor servers are required to actually
> >>       support protocol versions other than TLS 1.0; but the above rules
> >>       make sure that clients can operate in a backwards-compatible mode
> >>       without risking interoperability with servers following the
> >>       current specifications.
> 
> > 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.

> >             Similarly, clients that issue a STARTTLS command and don't 
> > send TLS 1.0 Hello messages are also BROKEN, full stop.  
> 
> Can you name an existing SMTP client with STARTTLS support that is not
> 'broken' by your definition?  

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.
That's not something that should be done lightly.

if you can define a set of rules by which old and new clients can
interoperate with old and new servers, without compromising security,
I would find that acceptable.  but I actually think it's more 
important to allow implementations *that followed the spec*
to continue to interoperate, as it is to allow implementations that
failed to follow the spec to interoperate.  (unless of course there
was a fundamental bug in the spec, which doesn't seem to be the case here.)

> > If a server wants to accept older Hello messages, that's its own
> > business.
> 
> This is not about 'older' Client Hello messages, this is about
> backwards compatible Client Hello messages -- old format, but new
> content.

yes, I understand the distinction.

> >            And servers would do well to parse older Hello messages
> > and continue with the TLS dialog even if they don't accept the
> > resulting client authentication as valid and don't treat the 
> > negotiated session as if it were secure - just because it makes
> > for better error recovery.
> 
> A backwards compatible Client Hello message does not mean that the
> connection actually uses the older protocol.  (And anyway, client
> authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
> cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)

hmmm.  I thought TLS 1.0 had fixed a few of these.
(but it's been a while since I analyzed it in detail, and that was
quite painful enough.)

> >                             But client implementations shouldn't 
> > expect that sending older Hello messages are going to make them
> > interoperable with servers that advertise STARTTLS. 
> 
> They cannot expect interoperability if they support only SSL 3.0 or
> even SSL 2.0, but that's not what this is about.  No-one requires
> servers to support SSL 3.0 or SSL 2.0; all that is required is support
> for backwards compatible Client Hello handshake messages so that it is
> possible for clients to tolerate SSL-only servers if they feel like
> it.  Backwards compatible Client Hello messages are described in the
> TLS RFC.

I think the problem is that you're adding a new requirement that would
keep conforming older servers (that did not recognize old format hello
messages) from interoperating with new clients.

Keith