Subject: Re: FAQ: SMTP Message Submission to Proposed Standard

From: Dave Crocker <[email-masked]>
Date: Thu, 14 May 1998 08:38:10 -0700

At 11:12 AM 5/14/98 -0400, Perry E. Metzger wrote:
>> The email industry desperately needs an authenticated submission
>> service.
>
>Given that relaying isn't authenticated, this strikes me as
>unimportant. Remember that SMTP is not an end to end protocol but a

This reaction is perhaps a good exemplar for what I suspect is the real
problem in this debate, namely that IETF technical work has gotten much
more specialized -- i.e., there are masses more of detail and context to
each activity -- and those of us -- yes, I said us -- who like to dabble
broadly often don't have quite enough background to get away with it.  One
might counter by saying that FAQ and other explanatory efforts need to be
thorough, but that's really an impossible task, if carried to its logical
extreme.

The need for submission-time authentication is to create a basis for what
is being called "first hop accountability", so that the service which
injects the message into the mail relay system can be help responsible for
allowing spam to be passed.

In other words, authentication now has a variety of purposes, not just to
permit the final recipient assurance of correct author labeling.  I'm a
large fan of end-to-end data object security, but this particular
requirement does not need it.

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

Sources which allow forged mail will come to find that sites no longer
accept mail from them.  Or they will find serious legal repercussions for
permitting spam to be injected.

>> (4) Why doesn't security protocol X solve all the problems?
>> 
>> MTA/MUA vendors have to sell products which work out of the box.  That
>> means they can't insist on the installation of custom TCP/IP stacks
>
>TLS requires no custom hacks. Its layered on top of TCP, and it is
>standards track.

Since when does the IETF require one and only one solution to be make into
a standard?

One of the other unfortunate aspects about this debate is that it has been
focused on security and spam, rather than email functionality and
architecture.

It's fine that we've gone so long without a separate posting protocol, just
as it was fine we went so long without a special relaying protocol.  But
the divergence between posting and relaying has been developing for a few
years and it's now time to make it official.

d/

_________________________________________________________________________
Dave Crocker                Brandenburg Consulting        +1 408 246 8253
[email-masked]      675 Spruce Drive        (f) +1 408 273 6464
www.brandenburg.com        Sunnyvale, CA 94086  USA

---

From: Chris Newman <[email-masked]>
Date: Thu, 14 May 1998 10:13:36 -0700 (PDT)

On Thu, 14 May 1998, Perry E. Metzger wrote:
> 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. 

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

> TLS requires no custom hacks. Its layered on top of TCP, and it is

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