Bernstein on SMTP tracing
Mark Crispin
deal with clueless kiddies and not with real hackers. Bernstein lists five
categories of people that have to be trusted in order for RFC-931 to work. To
this, let me add a sixth category: any user on a personal workstation. But,
you protest, we just disallow SMTP connections from personal workstations by
IP number and that solves the problem.
Titter. Giggle. Tee-hee. Ha ha. HAR HAR HAR HAR HAR HAR HAR.
Let me go further. I can send a forged message to an RFC-931 machine A that
alleges to be from a user (other than me) at RFC-931 machine B. I can do this
with a combination of knowledge and experience on the Internet (and ARPAnet
before that) that I have acquired in the past 18 years.
I am not unique; people with less knowledge and experience possess the
requisite knowledge to accomplish this as well. Fortunately, most of us are
on the side of the good guys, and most of the bad guys are quite clueless.
RFC-931 is alright against the clueless. Unfortunately, such measures tend to
motivate the clueless to get a clue before they possess sufficient maturity to
handle this knowledge responsibly. Personally, I think it is better to have
the wave of forged mail at the beginning of the school year and let the
novelty wear off. It also teaches mail recipients a healthy distrust of what
comes over the wire. RFC-931 does not, and can not, eliminate the forged mail
problem. It merely reduces it.
I also take offense at Bernstein's repeated bad-mouthing of the good work
being done by the PEM folks. I have no relationship to them, but I have been
tracking their work. They are trying to do something real, not a half-assed
hack that is UNIX-dependent and involves trusting a potentially large number
of people of questionable trustworthiness. What does Bernstein have against
PEM? It seems as if he actually is *opposed* to PEM now and in the future, as
opposed to merely pushing RFC-931 as an interim measure.
Dan Bernstein
> I hope that anyone who takes Bernstein's advice on using RFC-931 only has to
> deal with clueless kiddies and not with real hackers.
Mark and I are in violent agreement on most of the issues here. Nearly
all mail forgery is performed by clueless kiddies. As is, anyone who
reads the SMTP protocol spec can forge mail. With RFC 931, the number of
people who can forge mail drops dramatically---only the five categories
of people I mentioned before can control the usernames added to headers.
This makes the server well worth the minutes it takes to install.
> Bernstein lists five
> categories of people that have to be trusted in order for RFC-931 to work. To
> this, let me add a sixth category: any user on a personal workstation.
Someone who owns his own workstation and sends mail from it is in
category (2), so your sixth category is nonexistent. Besides, the mail
is tagged as coming *from that workstation*. Someone illegally in
category (5)---someone who can break TCP---can already destroy all
security mechanisms in wide use on the Internet except Kerberos. It
doesn't make sense to worry about those people when you haven't even
stopped forgery from the clueless kiddies mentioned above.
> Let me go further. I can send a forged message to an RFC-931 machine A that
> alleges to be from a user (other than me) at RFC-931 machine B.
I.e., category (5). You can break TCP.
> Personally, I think it is better to have
> the wave of forged mail at the beginning of the school year and let the
> novelty wear off.
Here's where Marc and I disagree. If you agree with his philosophy---if
you're satisfied with the current flood of forgeries---then you
shouldn't install RFC 931. I prefer to stop as many attacks as I can,
right now. RFC 931 provides such a high yield for so little effort---why
not use it?
> What does Bernstein have against
> PEM?
Mainly that it's vaporware. Nonexistent. Useless. Software which doesn't
exist is never useful.
---Dan
John Hascall
}This makes the server well worth the minutes it takes to install.
}Here's where Marc and I disagree. If you agree with his philosophy---if
}you're satisfied with the current flood of forgeries---then you
}shouldn't install RFC 931. I prefer to stop as many attacks as I can,
}right now. RFC 931 provides such a high yield for so little effort---why
}not use it?
High Yield? Well Worth...? Not in my experience; I ran it for a couple
of months and not once was it utilized (other than my tests).
I guess people here must `run with the wrong crowd', e-mail wise.
Having written a trivial daemon myself which always answers "root" or
"daemon" or "nobody" or whatever I want, why would I trust that any
other machine is running a `real' one?
John
--
John Hascall Our liberties we prize and our rights we will maintain
Project Vincent
Iowa State University Computation Center jo...@iastate.edu
Ames, IA 50011 515/294-9551 [fax -1717]
Dan Bernstein
> I ran it for a couple
> of months and not once was it utilized (other than my tests).
The implementations are too new to have been picked up by vendors yet.
For all practical purposes this protocol has only been around since last
February. But it's spreading; the wuarchive ftpd supports it, for
instance, and we've reached 100,000 RFC 931 packets/month across the
NSFNET T1 backbone.
> Having written a trivial daemon myself which always answers "root" or
> "daemon" or "nobody" or whatever I want, why would I trust that any
> other machine is running a `real' one?
Who's saying that you should? This is a crucial point: The true benefits
of RFC 931 accrue to *the person running the server*. The most important
example---the one which sparked this discussion---is the case of the
sysadmin who is asked ``Hey, which of your users forged this message?''
If he installs RFC 931 then he makes it much easier to answer that
question. The benefit comes back to him. If he installs an RFC 931
server which sits around spewing ``nobody'' then he won't gain this
benefit. See?
---Dan
John Hascall
}Who's saying that you should? This is a crucial point: The true benefits
}of RFC 931 accrue to *the person running the server*. The most important
}example---the one which sparked this discussion---is the case of the
}sysadmin who is asked ``Hey, which of your users forged this message?''
Maybe I'm just lucky that I can get away with answering "Don't know,
don't care, got real work to do...." ;-)
Actually, I can see real danger in running it here in that people *would*
trust it. So now Joe Evil writes the trivial daemon which always answers
"myenemy", boots one of our workstations in single user mode, mods /etc/rc
to run /tmp/rfc931.evil instead of the real one, boots up, forges a message
from "myenemy" which now has the "RFC931 stamp of authenticity", and then
undoes his dirty work. Now "myenemy" is in a world of hurt unless Bob
BigAdminGuy understands all of this. Admittedly, this isn't the work of
Joe Average Freshman, but there are plenty here who could do it if so
inclined. [Boy, everything comes back to physical security...]