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

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!

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

Sorry I didn't reply directly to your message. Here are the reasons I 
didn't include the suggested changes in -02.

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

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

Maybe "accept any certificate" wasn't clear. By accept, I also mean verify. 
The fact that a broken, unverifiable cert came in the negotiation is 
clearly not an interesting fact. In -03, I'll change "accept any 
certificate" to "accept any verifiable certificate".

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

"Acceptable authentication" doesn't mean "must be authenticated". As you 
say, the server may not care about the identity of the client.

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

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.

--Paul Hoffman, Director
--Internet Mail Consortium