Subject: Re: Little endians, big endians, and 16 bit eggs

From: John Levine <[email-masked]>
Date: 22 Jan 2005 06:03:38 -0000

>But the main difference is about control. Prefixes can be made up on
>the fly by whoever thinks about them, while types must be registered
>through a rather lengthy and contentious defined IETF process.

Au contraire.  If I want to invent a new RR type and use it among
friends, I can do so.  I only need to register it if I want to use it
widely and be confident that it won't collide with other uses.  Since
RR numbers are 16 bits, if I pick a number far away from the currently
assigned ones, the chances are good that I can use it for a long time
without anyone else stumbling into it.

By my reading of RFC 2782, the prefixes on SRV names are supposed to
come out of the IANA services list which used to be RFC 1700 and now
is http://www.iana.org/assignments/service-names.  Again, I can invent
whatever names I want for private use, but for public use I'd better
register the name to avoid collisions.  The name space for prefixes is
certainly larger than 16 bits, but I'd argue that 16 bits already
makes the chance of accidental collision low enough that the
difference isn't important.

To the extent that DNS software complies with RFC 3597 and passes
through unknown names and RRs without crashing or mangling them, I can
use either private RRs or SRV names just like I can use private TCP
ports so long as the hosts on each end agree what they mean.  The
practical difference is that at this point the chances that DNS
software will do the right thing with a funky name prefix are a lot
better than with a funky RR.

So I can't help but ask: does Microsoft have a schedule to bring their
DNS software into compliance with RFC 3597?  It sure would help
simplify the arguments about what to do.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andras Salamon <[email-masked]>
Date: Sat, 22 Jan 2005 11:39:01 +0200

On Sat, Jan 22, 2005 at 06:03:38AM -0000, John Levine wrote:
> come out of the IANA services list

I agree.  However, Christian Huitema was suggesting a TXT record in his
example, not a SRV record.

-- Andras Salamon                   [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Sun, 23 Jan 2005 00:56:18 -0500 (EST)

On 22 Jan 2005, John Levine wrote:

> friends, I can do so. 

You can do whatever you want among friends, including not using standard
protocols.  Of course, other groups may come along and use the same type
codes (intentionally or unintentionally)  and standardize the codes for
their defined use, rather severely "crimping your style", as it were.

Sometimes the reasons are proprietary. Sometimes not. The proprietary
reasons I can understand, if I don't agree with them.  But sometimes the
reasons are technically unsound. This is now without doubt the case with
SPF.  The juggernaut rolls on.  The MARID group found the SPF scheme to
have insurmountable technical problems, and shut down.  Yet, the SPF
proponents forged ahead despite the unresolved technical problems, and
indeed, pretending as though there are no problems. This unfortunately is
a common activity among the radical anti-spam crowd.  Examples include the
so-called "reverse DNS check", the "pop-before-smtp check", and other
failed anti-spam measures too numerous to list, that were described as the
way to end spam.

In presenting the SPF classic draft to this group, it is asserted that the
draft should be considered and standardized because some thousands of
domains (among millions) are using SPF. No mention was made that most of
the SPF-using domains are __spammer__ domains.  The number of users
pointing guns at their feet and pulling the trigger is no reason to
standardize the caliber of gun used to blow off toes.  The responsible
thing is to tell those users not to shoot themselves (or others) in the
foot. The irresponsible thing is to standardize the weapon used for
self-inflicted wounds, merely because some number of people have shot
themselves in the foot on the fervent irrational faith that doing so will
end spam.

Theorem 1:
"DNS is not suitable for authentication purposes."

Theorem 2:
"Any scheme that depends on DNS for its security is fundamentally 
unsound."

That includes (but clearly isn't limited to)
	Reverse DNS checking for spam
	RMX
	SPF
	Any other DNS Email Authentication scheme.

It is interesting that the common thread of Dr. Levine's involvement in 
DNSEXT has gone from 
	SPF I-D for review: draft-schlitt-spf-classic-00.txt
	Zone cut
	Engineering SPF
	wildcards vs. RR types, was Faux wildcards
	Little endians, big endians, and 16 bit eggs

Each of these discussons have the common thread of finding a new way to 
break or abuse DNS.  Perhaps the theorems 1 and 2 above should be studied 
more closely.

First, we discused RMX. That draft was rejected. Then, the idea was
resurrected again as SPF, ignoring the failures of demonstrated for RMX.  
In fact, a special group was created to standardize this. In spite of that
the MARID working group concluded that it couldn't overcome substantial
technical faults. Now, SPF is again resurrected, on yet another IETF
group, again ignoring the two previous failures.

Word has it on the old ietf-mxcomp list that the IETF may create a "DNS
Email Authentication" working group, apparently to specifically ignore the
Theorems 1 and 2 above by including the oxymoron in the name of the group.

So, perhaps merely refusing to ratify a draft is insufficent. Perhaps a
stronger statement on why the idea shouldn't merit further consideration 
unless a number of conditions are met first is necessary to stop the waste 
of time on such things.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000