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

The only change between draft-hoffman-rfc2487bis-01.txt and
draft-hoffman-rfc2487bis-02.txt (except a tiny modification to the
examples) is that the new section 5.3 specifies that STARTTLS is also
possible in the RFC 2487 Message Submission protocol; none of my
comments on ...-01.txt was taken into account.  Maybe the reason that
there were no replies to my message was that I sent it just to
[email protected] and not to [email protected] -- apparently most
messages that are distributed via ietf-apps-tls are cc'ed to both
lists, so possibly it's just that about no-one is subscribed to
ietf-apps-tls.  Anyway, here's that message again.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Wed, 11 Aug 1999 00:43:45 +0200 (CEST)
From: [email protected] (Bodo Moeller)
To: [email protected]
Cc: Paul Hoffman / IMC <[email protected]>
Subject: Re: Fwd: I-D ACTION:draft-hoffman-rfc2487bis-01.txt

draft-hoffman-rfc2487bis-01.txt:

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


> 5.1 Processing After the STARTTLS Command

>                                                           [...] some
>    general rules for the decisions are:

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

If the server accepts any certificate, then it should also note in the
"Received" header whether the certificate could be verified or not.
Just recording the subject's DN or the issuer and serial number, while
in theory providing enough distinguishing information, is not enough.
I think this should be stated explicitly here.


> 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 and the privacy level
provided by the cipher suite.  If anything is acceptable, the result
need not be checked at all.


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: Are client hello messages using the SSL 3.0 record format
acceptable?  (Presumably yes, but apparently no-one tries that anyway,
except when trying to negotiate SSL 3.0.)  What about SSL
2.0-compatible client hellos?  (Possibly not, in the sense that
servers should accept them, but clients should not generate them.)
Do implementations comply to the specification if they support only
SSL 2 or SSL 3.0?  Not everything in the Backward Compatibility
appendix of RFC 2246 makes sense, and it does not try to make definite
rules that apply to everything anyway, so it may be advisable to be
explicit in the specification for TLS-secured SMTP.  (RFC 2246 says
"Whenever a client already knows the highest protocol known to a
server [...], it should initiate the connection in that native
protocol" -- for STARTTLS, can it be assumed that the highest protocol
currently is TLS 1.0?)


Bodo M"oller
<[email protected]>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<