Subject: Why XML

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Jun 2004 08:38:25 -0700

All,

	I think that people need to see some examples of modern programming
that XML supports, these examples are in C#, but the metadata extensions in
the latest version of Java allow the same effect to be achieved:

	static XmlSerializer			keyInfoReader;

	// Construct the serializer class from KeyInfoType
	keyInfoReader = new XmlSerializer (typeof (KeyInfoType));

	// Parse a KeyInfoType structure using the generated parser
	KeyInfoType keyInfoData = (KeyInfoType) keyInfoReader.Deserialize
(stringStream);

What is going on here is that XmlSerializer is reading the metadata that
defines the KeyInfoType structure, generating code to parse that structure,
and running it through the parser to generate the class.

This could be done at compile time since the methods are all static.

The KeyInfoType class is annotated with metadata as follows:

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.w3.org/2000
/09/xmldsig#")]
[System.Xml.Serialization.XmlRootAttribute("KeyInfo",
Namespace="http://www.w3.org/2000/09/xmldsig#", IsNullable=false)]
public class KeyInfoType {
    
    /// <remarks/>
    [System.Xml.Serialization.XmlElementAttribute("KeyName",
typeof(string))]
	public string [] KeyName;

    [System.Xml.Serialization.XmlElementAttribute("KeyValue",
typeof(KeyValueType))]
	public KeyValueType [] KeyValue;

    ...
    }

This is considerably more verbose than it need be as this code was actually
generated directly from the schema using another tool.

A change to the schema can be accomodated without the need to change any of
the support code. I use the same code to parse XML data structures, save
them to disk etc in about six different programs.

This is not a new trick of course. People have done the same thing in LISP
for years, but that is not quite so interesting as there is only one data
structure in LISP.

The point is that you can only do this sort of thing if you have a regular
syntax for the data structure. ASN.1 and XML are regular enough to make this
possible.

I cannot write an SpfSerializer class, nor can anyone else. The rules for
parsing new data structures are unknowable.

The use of metadata is not an obscure programming idiom, it is the standard
way to code in the modern programming frameworks.

Writing flat code, without making use of metadata is in comparison like
writing code in assembly language. Sure I can do it, I used to write video
games in Z80 and 6502 assembler back in high school. But I would not write
an MUA in assembler and these days I would not write any sort of code
without metadata capabilities.

The angle bracket stuff is completely irrelevant as far as I and most other
XML coders are concerned. It is like x86 assembly code, I know it is there
but I don't want to see it.

		Phill

---

From: Roy Badami <[email-masked]>
Date: Tue, 22 Jun 2004 18:13:08 +0100

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> The angle bracket stuff is completely irrelevant as
    Hallam-Baker,> far as I and most other XML coders are
    Hallam-Baker,> concerned. It is like x86 assembly code, I know it
    Hallam-Baker,> is there but I don't want to see it.

However the angle bracket stuff is what most mail administrators will
find themselves staring at when debugging mail deliverability
problems.

That's my main reason for prefering SPF syntax; I just find it easier
to read (visually less cluttered) than XML, and its simpler (less
flexible) syntax is easier to parse visually, precisely because of the
lack of nested structure.

Am I overestimating the extent to which MARID records will end up
being written and read by hand by mail admins...?

      -roy

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 22 Jun 2004 19:19:28 +0200

Hallam-Baker, Phillip wrote:
 [ statement voting for XML ]

Folks,

I fully agree with Phil. There are pretty good reasons to choose
XML or ASN.1/DER. If you have a parser for XML or ASN.1, it will
be able to parse *any* version of records, even future ones.

Keep in mind that you are not designing some application
for LAN usage or for those who might want to give it a try.

This is about upgrading the world wide e-mail system. This
is a single-shot adventure. You won't get a second chance.

With ASN.1 or XML you can rely on the fact, that the
implementations can at least talk to each other even if
written for different versions of the data structures (after
all, that's what ASN.1 and XML have been designed for,
and there are good reasons why other protocols make
use of it). Application writers have learned that using
such a structured data language makes programs
better, more reliable, more secure, easier to extend,
and improves the compatibility between different versions.

Why ignore this?

I am working on network security and sender authentication
since around 1992 and was discussing about e-mail sender authorization
in context of RMX for about two years now. Believe me, you will never
be able to foresee everything what will come.
None of you should believe that he/she is able to design the
final protocol solving everything. Be
prepared to fail. What would you do if, maybe a year after the world
wide rollout, you suddenly realize that there is something you didn't
take into consideration? Maybe a new kind of attack? New spamming
technologies? New laws? New technology? Maybe a sender identified
by the mobile phone number instead of IP address? Any weird method
of time slots? Maybe topological authentication? Or maybe a completely
new directory service? Who knows? What makes you know that we
won't want to have a jpeg portrait image as a method of
authentication/authorization in three years?  Or any magic device
allowing us to send e-mail from every internet cafe authenticated?

What will you do then? Tell the world "Sorry, we made a mistake.
We have to reinstall the world wide mail system.  Please upgrade all
world's MTAs to the new version synchronously next
wednesday at exactly 11:30 am"?

The RMX syntax was a first approach, and SPF is not
significantly more modern. These syntax definitions are state of the
art - the art of about 10-20 years ago. We shouldn't ignore the
progress of computer science and programming technology.

How many changes and extensions will SPF syntax take?
Isn't every change and extension an odd hack? What makes
you rely on the fact that any new extension can be read by
any older version? With such a proprietary syntax as SPF,
every implementor will write his own parser/interpreter. I guess
that a new syntax version will break 5-30% of implementations.
In contrast, XML and ASN.1 parsers exist and are proven
and tested. You can automatically generate the parsers from
the grammar, thus eliminating lots of bugs and security flaws.

And as I stated earlier, don't be limited to today's point of view and 
today's
technology. Tomorrow there will be another killer application again
requiring protection against fraud and forgery. Maybe voice-over-ip.
Maybe instant messaging. What would you do? Start a new discussion
for two years and design a new proprietary syntax?

Keep in mind that this is a one-shot operation for upgrading
a world wide communication network which will only succeed if
the world wide communication remains working and compatible
without major problems. This requires an extensible, orthogonal
and precise definition and a robust and proven method to
describe data structures, where parsers can be generated automatically
and libraries are ready for use instead of reinventing another wheel.
XML parsers exist for most modern programming languages and make
it easy to write e.g. a graphical frontend. The art of programming
is abstraction between contents and representation. XML and ASN.1
do this all. SPF doesn't. Don't make the mistake to take your own
hacking (in)capabilties as a design criterion for a world wide 
communication
protocol. Parsing SPF is a hack. This makes it look easy and comfortable
in some people's eyes. But that's wrong. We are not here to design
a protocol easy to parse with perl regular expressions.

And, by the way, sorry, but can't resist, asking for "who can give
an example SPF isn't able to cope with, otherwise it must be good" is
not exactly the art of designing good protocols.

Or in other words: I vote for ASN.1 or XML (or zipped XML).

regards
Hadmut

---

From: <[email-masked]>
Date: Tue, 22 Jun 2004 13:27:29 -0400

I think you are correct Roy, I have, and will continue to manually code my SPF records.  And if I
wanted SPF XML records, I would have to do them by hand also (I don't have any XML encoding
software, not to say that there won't be any free ones, but I have far better things to spend my
software budget on right now).

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy Badami
> Sent: Tuesday, June 22, 2004 1:13 PM
> To: Hallam-Baker, Phillip
> Cc: IETF MARID WG
> Subject: Why XML
>
>
>

---

From: <[email-masked]>
Date: Tue, 22 Jun 2004 13:49:35 -0400

Um, how does the complexity of XML improve security.  I can think of examples where XML enhancements
CAUSED exploits, and there are implementations where the XML implementation poses denial of service
exploit by sheer processing power needed for a full XML parser.

How is this a "single shot" at upgrading email?  The SMTP protocol has been evolving for a VERY long
time.

Interesting arguments on extensibility.  All valid.  Also all valid for SPFv1 due to the fact that
SPFv1 is extensible.

Terry Fielder

> [mailto:[email-masked]]On Behalf Of Hadmut Danisch
> Sent: Tuesday, June 22, 2004 1:19 PM
> To: IETF MARID WG
> Subject: Re: Why XML
>
>
>

---

From: Chris Zumbrunn <[email-masked]>
Date: Tue, 22 Jun 2004 19:49:39 +0200

> but I don't want to see it.

Exactly, most everyone doesn't want to see it either. Which is why it 
doesn't belong in DNS.

If it would be true that XML is the format to use then DNS should only 
contain a pointer to it.

Chris

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 22 Jun 2004 20:15:41 +0200

>being written and read by hand by mail admins...?

Yes, you are overestimating it by far.

Most so called "mail administrators" are not able or not used to fetch
DNS records. They are what we call MuFF-clickers
(MuFF = Maus und Fenster-Firlefanz = Mouse and Window falderal)

By far the most domains (at least in Germany) are domains of
private people or small to medium size companies and organizations
which don't have a clue about DNS details, they are more or less
consumers of ISP services. Very few domain "admins" are able to
write a zone file. You have to give them a neat and easy user
interface, either some windows program or a web interface.
With debugging facilities - Enter an IP address here and see wether
e-mail would be accepted or not (and why).

Very few people will read or write those records directly without
software support. And much fewer people will be able to read
SPF but not XML. I guess <<2%.

I bet that MARID records will be handled through some software
frontend in >97%. So you can use ASN.1 or XML (or zipped XML)
as well. It makes writing such programs even easier.
There are ready-to-run XML parsers for PHP, Perl, Ruby, ...

Don't design the protocol for those few people who
fiddle around with DNS records directly.

Design the protocol for those who need to handle
tens and hundreds of thousands domains automatedly
and to provide a web interface.

Once we have defined a protocol, we should be
able to provide software to cope with it.
Microsoft should make a program to read, write, verify,
and debug those records easily and make it available,
and we should provide such software for Linux/Unix/
Web as well. it must be easy to use. No manual editing
of DNS records. Why? What do you think how many
mistakes will all admins make on the world?
Tell them to keep their fingers off and use a program which
generates valid (and tested!) records only. E.g. warn if
one entry blocks another. Or if RFC1918 addresses are given.
This is basically the same as configuring a firewall.

Nice feature: Run it against your local mailbox or MTA log file
and show which messages would have been accepted and which
would have been denied. This will help people to debug in advance.

Such software is needed anyway if the new protocol
is to be deployed in finite time. The more people use such
an idiot-proof frontend instead of typing in rubbish, the
easier it will be to roll it out.

Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 22 Jun 2004 20:38:08 +0200

>exploit by sheer processing power needed for a full XML parser.

I do trust a parser generated by a parser generator or a common XML
library much more than any hand-coded quick and dirty SPF parser.
There is not automated parsing tool for SPF, and a syntax like SPF
invites for a quick and dirty implementation. Eats valid SPF records.
But that's how buffer overruns are generated.

>How is this a "single shot" at upgrading email?  The SMTP protocol has been evolving for a VERY long

That's nonsense. The SMTP protocol was evolving at a time where
the "Internet" consisted of a few hundred users and where e-mail was
just an experiment, where nobody complained if it didn't work for some
time. e-mail was a researchers game, not a highly relevant communication
medium. SMTP had time and chance to evolve.

But to follow your argument: How much time would you like to have for
SPF to evolve? 3 Years? 5? 10?

>Interesting arguments on extensibility.  All valid.  Also all valid for SPFv1 due to the fact that
"Extensible"? You mean you can add new, unknown entry types. Is this 
"Exensibility"?

Is it possible to add a time limit to an IP address without loosing 
backward compatibility?

Can I extend an entry giving permission to the address 1.2.3.4 such that 
it is allowed
only during business hours, while keeping compatibility with older 
version (which would
give permission around the clock)?

What if I wish to add, e.g. cryptographic keys or jpeg images to the 
records? What if
an entry becomes 180,000 bytes long? Are you sure that all SPF 
implementations
will eat this without problem? No buffer limits?

Is SPF really "extensible"? Or is it just not well defined?
Is that what you call "Extensibility" more than just a gap in the 
definition?

Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 22 Jun 2004 20:40:35 +0200

> If it would be true that XML is the format to use then DNS should only 

Which was btw the reason for my RMX++ proposal. In RMX++ DNS just contains
the pointer.

Hadmut

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 22 Jun 2004 15:40:14 -0400

> interface, either some windows program or a web interface.

  Most such systems either:

  a) have a previously defined MX for the domain, which the user can't change

 or

  b) allow the users to add/edit MX's via the web interface.

  Both methods permit automated addition of a subset of MARID records.
This means that most of those users won't even know if MARID is being
deployed.  With 100x more domains than MX's, this kind of solution is
the *only* one which is relevant.

> and to provide a web interface.

  I agree.  If you have 100 domains for one MX, it doesn't make much
sense to administer those domains by hand.

  Alan DeKok.

---

From: Sean Comeau <[email-masked]>
Date: Tue, 22 Jun 2004 16:20:46 -0700

> But that's how buffer overruns are generated.

how about lex? 

> will eat this without problem? No buffer limits?

I don't see how XML would fare any better. The problem is that the 
record is 180K in size. XML parsers need to use buffers too. The
machines XML runs on also have limited amounts of memory. And we 
are not going to be putting 180K into a resource record. Crypto
keys have already been covered, jpegs can be handled in much the
same way.

> Is that what you call "Extensibility" more than just a gap in the 

Yes, SPF really is extensible. If we need to start dealing with
180K XML files later we can just add: 

ihopeyourmailserverhasLOTSofmemory=http://host.example.net/bloat.xml

After all, when faced with a 180K download the HTTP overhead isn't
a problem. Hopefully it won't come to that.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jun 2004 18:37:13 -0700

On Tue, 2004-06-22 at 11:38, Hadmut Danisch wrote:
> > Um, how does the complexity of XML improve security.  I can think
> > of examples where XML enhancements CAUSED exploits, and there are
> > implementations where the XML implementation poses denial of service

Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack.  Introducing a required series of DNS queries to
establish permissions increases a data footprint, but also code size may
also adversely impact system resources depending upon OS and structure. 
If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities.  The
less rigid and more extensible the syntax, the greater the
vulnerabilities.  As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.

An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs.  The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel.  If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn
also outsource for yet more chaining.         

As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF/CID mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 10 queries with an average of 5 seconds a query,
then this limits each process to about 1 message about every minute. 
These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second.  This may still represent the same amount
of network traffic, just half as much mail gets through the network.

The concern for the process footprint becomes important as this will
impact the number of simultaneous processes able to run on these
machines.  Should this mechanism only be usable at the MUA, there will
be no mitigation with respect to network traffic, as the MUA will
consume these same resources, invoke the queries, and even a valid
record does not offer assurance the mail is desired.  All of this
checking will provide a marking scheme that may be inaccurate depending
upon the number of users sending from diverse access points, and still
possibly forged, especially if checking is moved to the MUA.  If forced
into its strictest mode, it will cause complaints by forcing users to
offer a greater number of return addresses while at the same time
removing tools to consolidate the resulting diffusion of mail.  The
recognizable return address becomes a thing of the past.

By insisting records sizes be 20% larger to handle future extensions
where version 1 code must accept any and all additional "unknown" data
added to the record invites uncontrollable growth of these records. 
Should an MTA decide a series of 512 byte DNS records is not reasonable
because this addition, then those demanding extensibility will complain
such limitations are non-compliant with their "vital" need for something
else yet to be defined.  The further this gets away from the immediately
confirmable information using standard DNS queries, the less likely
there will be any discernible benefit. 
   
> > How is this a "single shot" at upgrading email?  The SMTP protocol
> > has been evolving for a VERY long time.
> 

As they say, there is more than one way to skin a cat. An extensible
protocol does not need to use an extensible record.  Mail is one of the
most often used applications.  Any feature added should not risk
breaking both the DNS system as well as the application that it is
claiming to improve.  If to stop abuse, aim directly at stopping abuse. 
Attempting to lessen a technique may change the behavior of the abuser
but will do little else. In addition, any false assurances adds to the
risk of clients being duped with possible suits directed to those that
provided false assurances.

> > Interesting arguments on extensibility.  All valid.  Also all valid
> > for SPFv1 due to the fact that SPFv1 is extensible.
>
> it is allowed only during business hours, while keeping compatibility
> with older version (which would give permission around the clock)?
> 
> records? What if an entry becomes 180,000 bytes long? Are you sure that
> all SPF implementations will eat this without problem? No buffer limits?
> 

Extensibility is the road to never ending change, paved by marketing
hype, that soon requires complete replacement due to lack of foresight.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Wed, 23 Jun 2004 03:58:04 -0500

>of network traffic, just half as much mail gets through the network.
My mail server already checks over a dozen RBLs, plus doing Razor, DCC, 
and slews of header and body regexp checks.
If MARID is effective enough for long enough that most spammers give up, 
then ....
This will be more realistic:

As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF/CID mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 4 queries with an average of 1 second a query,
then this limits each process to about _ message about every minute. 
These 4 queries will also add to the traffic at 50 bytes per record a
total of 0.2K bytes of additional traffic for a halving of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 4 seconds per process, the mail server has spare capacity up to
'only' running 4000 messages a second.  

Of course, CSV queries are efficient even if most of the queries are 
against spammer domains.

Also, you're assuming there are no DNS cache hits.

Also, if an SPF query starts with a blacklist check of the domain and 
that fails, then no further queries will be made.  That's efficient.
But yeah, spammers trying to gum up the works will result in what you're 
talking about.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2004 10:18:45 -0700

On Wed, 2004-06-23 at 01:58, Matthew Elvey wrote:
> and slews of header and body regexp checks. If MARID is effective enough
> for long enough that most spammers give up, then ....

Unlike these queries in parallel to _known_ servers, the SPF/CID schemes
involve a series of queries to _unknown_ and possibly hostile name
servers.  The SPF/CID _may_ be effective against some false
representations, but expect these mechanisms to just change the mode of
this fraud.  Don't expect SPF/CID to reduce levels of abuse.  These
schemes fail to stop rogue systems dumping volumes into the channel.  In
addition, any assurances offered recipients will only bolster fraudulent
claims.  Expect such fraud to happen more often when channel checking
becomes depreciated due to constant attacks.  Now those defrauded have
cause against those providing false assurances.
    
> seconds should be considered a worst case resolver interval.
-
> If there becomes an average of 4 queries with an average of 1 second
> a query, then this limits each process to about _ message about every
> minute.

These are messages from hostile domains.  Where is there a 4 query limit
to fully resolve permissions?    
 
> load.

In addition to this estimate ignoring the actual size of the query
response, this tread is discussing a requirement that the MTA _MUST_
accept large results even if the information contained is unknown.  This
was to allow "new" features added at 100 bytes a whack at the whim of
vendors.  

> The mail server may normally handle 1,500 simultaneous processes,

This may be a typical baseline before being taken down to 25 messages
per second by the attack scenario previously described. 
<snip>

> Also, you're assuming there are no DNS cache hits.

The cache may be invalidated by small TTL values as stated in the mode
of attack.  If not, what is the typical cache size and how many entries
are typically supported in the DNS cache?  Causing a flood of 350 byte
responses into the DNS cache will impact more than just mail service. 
At 250 per second as described, a minute of such may consume 10 M bytes
of DNS cache.  This assumes there is a local caching name server and
results are not isolated to individual processes.
 
> But yeah, spammers trying to gum up the works will result in what you're 

If to assure the recipient of the sender's identity, Fenton's Identified
Internet Mail proposal stops identity fraud with two determinate queries
where fraud is truly curtailed without changes to SMTP.  The added
overhead for the Fenton proposal is about 600 bytes carried mostly in
the SMTP and HTTP stream, where DNS simply returns a single SRV record
pointing to the key server.  Fenton's scheme has a chance of working and
can isolate efforts for critical communications rather than across the
board.  In addition, it would be reasonable to trust assurances offered
by the Fenton proposal.  That must not be said of the SPF/CID proposal. 
As an RBL check against the address of the MTA is the primary protection
scheme, not SPF/CID, requiring a single query for an SRV record to check
the EHLO domain would allow greater assessment and better protections by
then also enabling RHSBL.  This would also enable enforcement efforts
against abusers, unlike abuse sorted by users with the SPF/CID
proposals.  SPF/CID fails to assert an accountability claim by the mail
sender.  This leaves the door open to abuse unabated.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Fri, 25 Jun 2004 16:47:17 -0500

On 6/23/04 12:18 PM, Douglas Otis sent forth electrons to convey:

>>>intensive attack.  ...
>servers.  
I know that.  I did read the first sentence above!  I was CLEARLY 
discussing best case. You just didn't notice.
Certainly, worst case is also important.  More important, in fact.  But 
best case is important too.

>These are messages from hostile domains. 
>
NO THEY ARE NOT.  You didn't read my post, particularly what immediately 
preceeded the above quote/read it selectively.
Please do not quote me misleadingly again.  Grr...

What kind of selective misquoting are you up to?  You cut this:
"If MARID is effective enough for long enough that most spammers give 
up, then .... " !!!
Sheesh!

>response
No; see ?wayne's? data on typical SPF record sizes.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 Jun 2004 15:15:17 -0700

Matthew,

This was in regard to an attack scenario with motivation given for such.
Surprisingly, you base performance using known servers for your best
case scenario.  In addition, estimates for a DNS response from the the
TXT record query must include the size of TXT record with another 56
bytes and the size of the name referenced.  I put together what I
thought could be considered a reasonable set of circumstances allowed by
the draft.  I did not take this to an extreme.  I wanted to illustrate 
difficulties identifying these attacks with their potential impact on
performance.

Even if there are messages processed quickly, the slower messages will
very much dominate the load on the servers.  As SPF allows open lists,
these attacks may never reference any domain or name server owned by the
attacker.  Should this attack be distributed to many destinations, then
the name servers should be expected to become erratic where this will
help sustain the attack.

SPF never directly establishes the domain accountable for the mail
stream.  As a result, finding a method of stopping a flood of abusive
mail must depend upon methods outside of the SPF.  Identification
methods available to commerce and advertising could implement the Fenton
"Identified Mail" proposal without jeopardizing mail services and this
completely guards against identity fraud.  SPF interferes with the
normal use of mail as well as the Fenton proposal in that it attempts to
tie identity to the mail channel.  CSV on the other hand protects
against abusive domains without increasing risks from attack and leaves
the use of mail unchanged.  CSV allows follow-up should there be
criminal fraud and allows policy evaluation of the domain handling the
mail.

The types of information gleaned from SPF and CSV are similar in that
they both identify outbound SMTP servers.  A difference for CSV is that
it is comprehensive in that it limits identity to the domain accountable
for the mail stream, whereas SPF attempts to correlate domains permitted
to carry mail for other domains.  As this SPF correlation is never
expected to be comprehensive, either this list must be defined as "open"
or a method to "usurp" this permission must be allowed.  Either
exception keeps the door open for abuse and fraud.

If SPF is not checked at the channel, then assurances provided the
recipient by the SPF mechanism is highly suspect and provides
motivations for attack. SPF will also likely lead to greater
restrictions on the use of mail addresses and the ability to forward
mail to a common account.  Both of these outcomes will be onerous for
users and providers and again offer motivation for attack.

CSV does not change the way mail is used and, for most users, they will
only notice a reduction in abuse as it can quickly identify infected
systems.  Unlike an address method of vetting a sending SMTP client, use
of a domain name allows a greater history to be acquired, even where the
address may be dynamically assigned or shared and allow assertions of
affiliations.  Vetting a domain name that handles the mail allows
greater speed and accuracy as opposed to only an IP address.

-Doug

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 28 Jun 2004 09:55:34 -0700

Removing [email-masked] from the cc list; they're not going 
to abandon their scheme, and they can't address these issues without 
doing so; the right place for discussion is therefore MARID.

>difficulties identifying these attacks with their potential impact on
Yes, I would like to confirm that I think your scenario is more than 
reasonable: it represents a likely scenario at some point, should SPF be 
the base of MARID.

>the name servers should be expected to become erratic where this will
Sender ID, IIRC, at least suggests that SPF records that require > 20 
queries to resolve are inappropriate.  SPF should adopt this, or 
something stronger, as well (it says something more vague).  Even if 
this was adopted, the DDoS exposure is large.

>exception keeps the door open for abuse and fraud.
Can you give an example?  I'm not sure I follow.   Are you referring to 
SPF being 'optional', or what? 

>users and providers and again offer motivation for attack.
Not onerous given Unified SPF, which I think you're familiar with.  
These folks are very unlikely to attack the system.  Spammers are likely 
to attack the system.  (Where by attack, I mean not just in the 'argue 
against' sense, but a real military (e.g. DDoS) sense.)

>greater speed and accuracy as opposed to only an IP address.
If it turns out that SPF adoption leads to significant network harm, 
then it would be possible to tweak it or replace it with something more 
effective, with narrower scope, in particular CSV.   This is a valuable 
discussion.  Let's flesh out more your attack scenario, so we can be 
proactive about this. 
I could see SPF causing some free DNS providers to go belly up.  OTOH, 
DNS is a remarkably efficient protocol, so perhaps SPF is sufficiently 
lightweight.
It seems that traditional BLs were near the tipping point- concerted 
DDoS attacks brought down some BLs, but were unable to take down 
others.  MARID should be more stable than that. 
I think we may need to wait for Unified SPF to become an I-D; it's 
difficult to flesh out its DDoS exposure right now.  I suspect it is 
more resistant.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jun 2004 11:38:27 -0700

> reasonable: it represents a likely scenario at some point, should SPF be 

CSV and then SPF if at all.  I should also note to assess traffic caused
by these queries, the byte count should also include Ethernet (26), IPv4
(20), and UDP (8) overhead for an additional 54 bytes.

> this was adopted, the DDoS exposure is large.

Yes, but sadly Sender-ID never ensures accountability to enable
repudiation services a means to stop abuse.  Sender-ID leaves the door
open for abuse and thus can never offer protections from any type of
DDoS attack.

> SPF being 'optional', or what? 

SPF does not identify the domain injecting the mail stream. Nor does SPF
demand lists being referenced by the message domain to be "closed." 
This means a repudiation is meaningless if done on "unknown" in the case
the list is "open" and the address of the sending SMTP does not match. 
There is no rejection of the message nor an assessment made against a
domain if this message is found to have been abusive.  The case of a
domain "usurping" permission in SPF is no different than CSV.  CSV
treats all domains in this manner and allows no exceptions.  This means
for CSV, only a single query will provide a much smaller and yet
comprehensive block record that has the sole purpose of assigning
accountability irrespective of message content.

There are much stronger and more scalable means to identify the author
of a message such as the Fenton "Identified Mail" proposal.  There are
much more dependable means of establishing mail channel accountability
such as CSV.  SPF does neither of these functions well, but at a much
great risk in terms of causing return addresses to be problematic and in
creating DDoS attacks.

> against' sense, but a real military (e.g. DDoS) sense.)

There are significant problems using a SPF TXT record for CSV.  CSV uses
the HELO domain and not the return path domain.  This record must be
specific about the domain sending the mail stream to accurately assess
accountability.  Such an assessment is not enabled by the SPF record. 
The resolution of the HELO domain will likely require a specific record
label different from that of SPF.  I see the SRV record being far more
appropriate for use with CSV for these reasons.  If there is to be
"unification," I would hope to see a required channel check using CSV
and then, if there is a desire for "protections" offered by SPF, perform
these SPF checks in parallel but of course using SPF records.

> discussion.  Let's flesh out more your attack scenario, so we can be 

Keep these two specifications separate and apply CSV first for both
accurate repudiations and for the protections needed for the possible
implementation of SPF.

> DNS is a remarkably efficient protocol, so perhaps SPF is sufficiently 

I fail to see how publishing the correlation of users to domains is ever
going to be lightweight.

> difficult to flesh out its DDoS exposure right now.  I suspect it is 

I see genuine value in moving CSV forward irrespective of the deployment
of SPF.  I see much better ways to identify authors and again point to
the Fenton proposal as how to strongly identify the author without
breaking mail.  I expect CSV being a far more effective tool against
mail abuse and a far more effective tool for enforcement.

-Doug