Re: bozoproofing the net, was The Value of Reputation

> Indeed.  And, along the lines of my response to John, and to
> Dave's request to be specific, that sort of analysis and
> description is _precisely_ what I believe should be required to
> be written into text, ...
The more I think about this, the less sense it makes.  DKIM is not the
first misusable security technology to come along, nor will it be the
last.  What makes it so uniquely dangerous that it needs special warning
labels?

Consider HTTP over SSL.  It has exactly the same balkanization problem
today that you're concerned about.  Browsers are shipped with a fairly
random list of signing certs that have more to do with history and PR
budgets than with an objective standard of merit, and pages from any https
server that hasn't bought a signature from someone in the browser's list
provoke a scary warning message.  Yet I see no language in RFC 2818 or in
sections 2.3 and 2.4 of RFC 2459 (user and administrator expectations)
warning about the problem of balkanization due to arbitrary signer lists.

Or consider S/MIME.  S/MIME applications have a cert list similar to the
one in a web browser, so they also have the problem of dividing the world
into haves who can afford a cert with a signature from someone in the list
and have-nots who can't.  I haven't read every word of every S/MIME RFC
(there sure are a lot of them), but if there's any warnings about
balkanization, they're very well hidden.

Or how about DNSSEC?  As the problems of phishing and malware get worse,
and ICANN and IANA start putting signatures into the root zone, people
will inevitably come up with the bright idea that names in signed zones
are "secure".  Even better, in the absence of signatures all the way to
the top, people will start making lists of the islands of security that
they like to limit which signed zones they accept.  I would think that
warnings about this would have belonged in RFC 4033.

I really need clarification of why DKIM RFCs need to tell people about the
dangers of balkanization, even though HTTPS, S/MIME, and DNSSEC don't.
Since we will certainly be seeing more anti-spam and anti-phishing
proposals, what would be really useful would be a metric to decide when a
future proposal is more dangerous like DKIM and requires warning language,
or is less dangerous like the other three and doesn't.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf