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

[Bodo Moeller <Bodo_Moeller@xxxxxxxxxxxxxxxxxxxxx>]

On Sun, Sep 12, 1999 at 11:00:31AM -0400, Paul Hoffman / IMC wrote:
> At 07:03 PM 9/11/1999 +0200, Bodo Moeller wrote:

>> The only change between draft-hoffman-rfc2487bis-01.txt and
>> draft-hoffman-rfc2487bis-02.txt (except a tiny modification to the
>> examples)

> A tiny modification that corrected an error!

Sure, no doubt about that.

>>> 3. STARTTLS Extension

>>>    After receiving a 220 response to a STARTTLS command, the client
>>>    SHOULD start the TLS negotiation before giving any other SMTP
>>>    commands.

>> Is there any server implementation that can handle the case where a
>> client sends SMTP commands in clear after the 220 response to
>> STARTTLS?  (If so, why?)
>>
>>      After receiving a 220 response to a STARTTLS command, the client
>>      the client MUST NOT give any other SMTP commands before having
>>      started the TLS negotiation.
>>
>> would make much more sense to me.

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


>>> 5.1 Processing After the STARTTLS Command

>>>     - A publicly-referenced  SMTP server would probably want to accept
>>>       any certificate from an SMTP client, and would possibly want to
>>>       put distinguishing information about the certificate in the
>>>       Received header of messages that were relayed or submitted from
>>>       the client.

>                            [...] In -03, I'll change "accept any 
> certificate" to "accept any verifiable certificate".

Ok.


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


>> The draft only talks about TLS (except in one sentence that claims
>> that TLS is "more commonly known as SSL").  Backwards compatibility is
>> an issue: [...]

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