Re: draft-hoffman-rfc2487bis-03.txt

[Lutz Jaenicke <Lutz.Jaenicke@xxxxxxxxxxxxxxxxx>]

On Wed, Aug 16, 2000 at 03:34:10PM -0700, Paul Hoffman / IMC wrote:
> Greetings after a long time. I updated that rfc2487bis draft a month 
> ago but forgot to tell this list. Could all the folks who have 
> implemented STARTTLS for SMTP please review the draft and comment on 
> any changes needed? There is a list of the changes at the beginning 
> of section 1.

Ok :-) The new draft reflects the discussions taking place on
ietf-apps-tls with respect to STARTTLS for SMTP. I think it is a worthful
improvement of RFC2487.

I would like to discuss some points.

[Section 5]:
   After receiving a 220 response to a STARTTLS command, the client
   SHOULD start the TLS negotiation before giving any other SMTP
   commands.

I would prefer MUST here instead of SHOULD. At the point given, the server
expects the TLS handshake to be initiated by the client by sending the TLS
ClientHello message. In order to be able to deal with the SHOULD condition,
the server software must be able to intercept the TLS handshake and "guess"
from the bytes coming in from the client, that this is another SMTP command
and not the ClientHello message. Depending on the implementation that may
be difficult to realize.
I don't think a MUST is too strict here. A client software must be able to
decide whether it is able to start a TLS handshake and only send the
STARTTLS command if all necessary conditions are fulfilled.

[Section 5.1]:
    - A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.

This is a sufficient description for a MUA. The MUA has an entry for the
mailserver to be used and can check the server certificate against this
entry.
It is however not clear to me how a client MTA should handle this topic.
The MTA will obtain the server's name by performing a MX DNS-lookup, which
should return the canonical name. This name can however be different from
a CNAME given to customers.
Example: The mailserver "server.dom.ain" has the CNAME "mail.dom.ain" which
is given to customers as the address to submit emails with their MUAs.
Hence, the server certificate should be issued for "mail.dom.ain".
A client MTA will however try to contact "server.dom.ain" and will not be
able to authenticate the server.
This raises several points:
* The DNS lookup has to be considered insecure. Shall we think of an extension
  to the STARTTLS protocal such that the server can present another certificate
  based on the _recipient_ email address? HTTP is redesigned in this manner
  to allow name based virtual hosting.
* Another possibility would be to use the dNSName feature in the
  subjectAltName field. What names should be included?
  All CNAMEs for the server and/or the names of the domains this server
  receives email for?

[Section 7]:
   A server announcing in an EHLO response that it uses a particular TLS
   protocol should not pose any security issues, since any use of TLS
   will be at least as secure as no use of TLS.

I am not sure I missed something: does this mean that a server can announce
a particular protocol in its EHLO response, such as
   250 STARTTLS SSLv3 TLSv1
I have not seen this described before.

Best regards,
	Lutz Jaenicke
-- 
Lutz Jaenicke                             Lutz.Jaenicke@xxxxxxxxxxxxxxxxx
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153