Re: SMTP/TLS (RFC 2487) server authentication question

On Fri, Jan 28, 2000 at 09:05:24AM +0000, [email protected] wrote:
> From R.L. Morgan <[email protected]>
> > Excellent point.  I believe that the method defined in
> > draft-ietf-tls-http-upgrade-05.txt specifically provides this
> > functionality (for HTTP 1.1), via the Host: header.  But it seems to me
> > that all the other foo-over-TLS specs (SMTP, IMAP/POP/ACAP, LDAP) are
> > deficient in not providing this.  Ironically if it were there this would
> > be a real operational win for the STARTTLS approach vs the separate port
> > approach which has no opportunity for the client to express anything
> > before the SSL/TLS handshake starts.  
> 
> > So:  I submit that all these specs should be changed to add an optional
> > parameter to the STARTTLS command in which the client would put the name
> > of the service that it is intending to contact; to be used by the server
> > (optionally) to select a cert to be supplied to the client.  It may still
> > be possible to fix the LDAP doc.
> 
> I fully agree to this, it's even backword compatible. The smtp implementations
> who support TLS I know of (postfix, qmail, and ours) send back
> "501 Syntax error (no parameters allowed)", so detecting the "version" would
> be easy in an implementation. At least with SMTP, IMAP and POP3
> (first send "STARTTLS domain" if it doesn't work try "STARTTLS").

Sounds reasonable. RFC2487 as of now explicitely defines STARTTLS to have
no parameters, so extending the syntax would be no problem. If no "domain"
is given, send back a standard server certificate, otherwise send the one
requested.
What should be sent back in case the requested certificate is not available?
This case would need to be defined:
- 5xx Cannot serve required domain (no certificate available)
- Just start the TLS negotiation and send back the standard certificate.
I would think, that the first alternative is better, because it would allow
the client to react flexible and ask for another "domain" if it suites the
client.
Example: Send mail to [email protected], primary MX is my
serv01.aet.tu-cottbus.de, backup MX is the university's computer center's
mailserv.tu-cottbus.de (real names fit in here, you will find them with
nslookup anyway :-).  When delivering to serv01.aet.tu-cottbus.de, you
would probably succeed with "STARTTLS aet.tu-cottbus.de", but the mail 
server of the computer center might not have a certificate for all subdomains
(approximately 130), so when connecting to the backup MX you would like
to try "STARTTLS aet.tu-cottbus.de" and then "STARTTLS tu-cottbus.de",
if your client policy allows.

Best regards,
	Lutz Jaenicke
-- 
Lutz Jaenicke                             [email protected]
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