Re: FAQ: SMTP Message Submission to Proposed Standard

[Chris Newman <[e-mail]>]

On Thu, 14 May 1998, Perry E. Metzger wrote:
> Given that relaying isn't authenticated, this strikes me as
> unimportant. Remember that SMTP is not an end to end protocol but a
> hop-to-hop protocol.  This means that the only real security that can
> be provided for it is object security, like S/MIME.
> 
> Authentication of submission is nice, therefore, but not "critical".

S/MIME (whenever the standards track version is completed) will
authenticate the author of the content of the message to the user at the
other end.  It solves a different problem.

Authenticated submission authenticates the submission of the content,
headers and envelope of the message to the submission server.  The
submission server's authentication of the submittor is completely
independent of the end-to-end S/MIME security problem.

Like it or not, the owner of the submission server is partially
responsible for what messages are sent out to the Internet (e.g., to
cancel spammer accounts, fix serious protocol violations which kill remote
servers, track down the sender of a message which threatens to kill the
president, etc).  Therefore it _is_ a requirement that the submission
server be capable of authenticating the submittor.  And this is critical. 

> > (2) Why have a separate submit port?
> > 
> > Submit and relay are separate services.  Submit needs to have more
> > stringent validation of content,
> 
> I dispute that. If you can forge a submission via forged messages to
> the relay, then why will stringent validation on ingress help?

Thanks to spam, all unauthenticated relays have to be adjusted so they
only relay to approved machines (usually only local machines).  That's
necessary to prevent the major spam fanout abuses.  Submission servers
will relay the message anywhere assuming the user has appropriate
authorization.  And because a submission server only processes outgoing
email, it can afford the time necessary to be much more picky about what
it accepts.  Because it's interactive, it has a chance to return
diagnostics back to the user -- diagnostics which would be inappropriate
on a relay action. But if the two services aren't separated, the combined
submission/relay server can't do any validation which might slow or damage
the normal flow of incoming email and it's restricted to diagnostics
suitable for relay connections.

> > (4) Why doesn't security protocol X solve all the problems?
> TLS requires no custom hacks. Its layered on top of TCP, and it is
> standards track.

What are the standards track RFC numbers for TLS and the SMTP profile
thereof?

> > the purchase of certificates from Verisign before working.
> 
> Not necessary, either.

Are you sure about that?  To interoperate with deployed clients, a server
has to:
(1)  Support SSL as well as TLS
(2)  Use the RSA / RC4 cipher suite (and support 40-bit encryption keys)
(3a) Purchase a certificate signed by one of the CAs that's built into
     all the clients in use.
 or
(3b) Generate a self-signed certificate and manually reconfigure every
     client on site to accept that certificate (at some sites this can be
     done by telling users to say "OK" to the appropriate dialog box).
(4)  Generate an manage client certificates for all users.  This has
     proved to be very hard in practice.  It's hard to find a web server
     which actually uses client certs.

Granted, this is a viable solution for some sites -- especially ones where
the users are capable of setting up their own client certs, but it's not
viable at most sites.  And it's very hard for some MUA/MTA vendors for
various reasons.  So TLS is a useful tool at times, but by itself, it only
solves the authenticated submission problem in a fraction of the real
world cases. 

		- Chris

"Good security is hard.  X.509 is harder."