Re: I-D ACTION:draft-hoffman-rfc2487bis-02.txt

At 01:13 AM 9/13/1999 +0200, Bodo Moeller wrote:
> > The client might have to stop after the 220, such as if it realized 
> that it
> > couldn't really start TLS. Thus, the client should be able to issue a 
> QUIT.
> > Your proposed MUST NOT would prevent that.
>
>Deliberately, because forcing server implementations to be able to
>recognize both protocols (clear SMTP and TLS handshake) complicates
>implementation without really having any significant benefit: The 220
>response to STARTTLS should not come as much of a surprise to the
>client, or it should not have sent the STARTTLS command in the first
>place.
>
>Is there really any (alleged) RFC 2487 server implementation that
>continues as specified when the client sends clear SMTP commands after
>the 220 answer to STARTTLS?

These are good questions. If no one *could* handle a text QUIT at that 
point, Bodo's MUST NOT seems sensible. It would mean that, if a client 
wanted to say "whoops", the only way would be to drop the connection, but 
that is probably better than confusing the TLS stack with unexpected garbage.

> >>> 7. Security Considerations
>
> >>>    Both the STMP client and server must check the result of the TLS
> >>>    negotiation to see whether acceptable authentication or privacy was
> >>>    achieved. Ignoring this step completely invalidates using TLS for
> >>>    security.
>
> >> "Both ... must" is too strong, because in some cases one of them (a
> >> publicly referenced SMTP server) may not at all care about the
> >> authenticated identity of the other SMTP [...]
>
> > "Acceptable authentication" doesn't mean "must be authenticated". As you
> > say, the server may not care about the identity of the client.
>
>Maybe we can agree on something like "... whether an acceptable degree
>of authentication or privacy was achieved"?  (Also the "or" should
>really be an "and", and I just noticed that "STMP" contains a typo.)

I'm fine with this wording.

> > I believe that these are all outside the scope of this document. We can
> > only normatively reference TLS, not SSL. If an implementor wants to accept
> > SSL connections, that's up to them, but not specified in the document.
>
>It's not about accepting SSL connections -- I agree that they are out
>of the scope of a specification for an application of TLS --, it's
>about client hellos that request a TLS connection, but use a
>backward-compatible record format for compatibility with SSL-only
>servers.  This is an issue even if both the client and the server in
>fact do support TLS 1.0.  RFC 2246 contradicts itself on these issues
>(more exactly, taking RFC 2246 literally could lead to
>non-interoperable applications), so there's a reason for treating them
>with special care in application specifications.  One of the things
>RFC 2246 says is that "TLS 1.0 clients that support SSL Version 2.0
>servers must send SSL Version 2.0 client hello messages", so even TLS
>1.0 servers will see client hellos in SSL 2 format if there are any
>clients that want to be able to talk to SSL 2.0 servers.  If we
>exclude SSL 2.0 and the SSL 2.0 client hello format totally, there's
>still a similar situation for SSL 3.0 vs. TLS 1.0 -- implementing TLS
>servers that tolerate this kind of backward compatible TLS clients is
>much easier because the data formats are nearly the same, but it's not
>quite clear what server implementations can be expected to accept.

OK, I'm unclear what you're asking for here. What words would you want 
added to the spec to handle or not handle SSL 2.x and 3.0?



--Paul Hoffman, Director
--Internet Mail Consortium