ietf-mxcomp
[Top] [All Lists]

RE: Reuse of TXT : draft-ymbk-dns-choices-00.txt

2004-05-17 22:48:46

Some MARID specific points to ponder:

With the hope being that MARID is a powerful weapon to be 
used to fend 
off spam, it is only a logical conclusion that spammers will 
resort to 
attacks on the DNS given their past redoubling of efforts to defeat 
anti-spam measures.  

I don't think that the DNS is likely to be the attack target for
spammers. 

A successful DNS spoof could be used to cause a single recipient 
to accept spam from the attacker under the pretense it was from
the impersonation victim. That is certainly not a method that is
practical for most types of spam. The attacks against the DNS
infrastructure are not simple and leave clear evidence of attack.

If this were to become a problem it would be necessary to deploy
security for the DNS. Regretably the DNSSEC specification is
not currently an option for reasons that are well known to you, 
the IESG and the IAB. But the ten year old DNSSEC proposal is
not the only one possible.

A more practical approach would be to modify the TSIG mechanism 
by extending it to support a key exchange mechanism. This would 
have the added advantage of providing a natural means of 
introducing encryption which is a key weakness of the original
DNSSEC requirements gathering that took place over a decade 
ago in an environment that bears no resemblance to that of today.

I think that is is far more likely that the aggressivge spammers
will reroute BGP blocks than try attacking the DNS.


Therefore, it is possible to define a new record type with a 
more bandwidth efficient binary format or perhaps a tokenized or 
compressed form of a more verbose text syntax.  However, it should be 
noted that new DNS record types cannot take advantage of the existing 
DNS label compression.

There is significant value in representing 10.0.0.1 in four bytes 
rather than 8. But further compression techniques are not worth 
the hassle. The problems we face come in two sizes, two small to
be a problem and too large for cutesy hacks to provide value.


Consideration should also be given for the need of wizards and other 
administrative assistance software in the face of complex 
text syntaxes 
(one example of this type of software may be found at 
http://spf.pobox.com/wizard.html).  The familiarity of these syntaxes 
by protocol developers should not be conflated for ease-of-use by 
network administrators lacking the luxury to understand intimate 
details of all aspects of systems they administer.  It is not 
unreasonable to conclude the necessity of wizards for mass acceptance 
of a MARID solution.

I don't think that administrator simplicity is the motivator here.
The big problem is that getting any form of infrastructure update to happen
in the real world is hard. Systems that depend on new software being
deployed are likely to be less widely deployed than those that require
update to a new and possibly buggy version of DNS software.

The risk that this group must consider is that the MARID spec is
promulgated but SPF becomes the defacto standard.