Re: [Asrg] Re: 3. Problems with domain keys and with message-body-authenticator

[Everton da Silva Marques <evertonsm at yahoo.com.br>]

> On Fri, 28 May 2004, Everton da Silva Marques wrote:
> 
> > --- William Leibzon <william at completewhois.com> wrote:
> >
> > >
> > > Your MBA is not scalable as it requires dns
> > > record for each message that passes through the
> > > system. This is called message tracking and dns
> > > is not good procotol to be used for such
> > > purposes as frequent updates will need to be
> > > done to dns zone file
> >
> > It scales by consuming aproximately 8gb for each
> > 100 msg/s outbound rate.
>
> The scalability problem is not due to size of
> the protocol data bue due to necessity to make
> frequent updates to dns and large zone file that
> is the result.

8 Gb is an estimative for the zone size. It could
be kept in RAM for performance and periodically
dumped to disk, for safety. Yes, it could still
suffer from issues with current DNS software, but
that's not a real problem, since MBA is not bound
to using DNS as database service.

> > > (so TTL will have to be kept very low and
> > > caching is not possible, which is main advantage
> > > of dns protocol)
> >
> > TTL won't have to be kept low, as the RRs aren't
> > updated once published,
>
> That is not correct, the zone itself needs to be
> updated with every message that passed
> through. This requires very very low TTL

In order to publish hashings for MBA, only the SOA
serial would need increment.  With DNSSEC, the SOA
RR set may also need to be re-signed.  Again, TTL
is irrelevant here.

> > but there would be little gain on keeping them
> > high in this case anyway.  The TTL mostly does
> > not matter here. BTW, there is at least one
> > article opposing TTL as main advantage of dns
> > protocol: DNS performance and the
> > effectiveness of caching
> > http://portal.acm.org/citation.cfm?id=581877&dl=ACM&coll=portal
> 
> I don't know your background and experience with
> DNS but I've been dns admin from 1990 and can
> tell you that this article is not correct and
> that proper TTL is very important. It is basis
> of why the dns protocol is successfull because
> it allows for cashing of data by intermediate
> dns servers (The other most important feature of
> dns is using small udp packets for responses)

The article does not say TTL is unimportant. It
shows the main DNS scalability factor is the
partitioning of the namespace among many
servers. Of course caching helps, but the
importance of high TTL is often overestimated.
Such a discussion does not affect MBA though.

> > > large and that creates problems with
> > > DNSSec. This system is completely unusable
> > > for any large company.
> >
> > Can we define large company in numbers? How
> > about 100 msg/s outbound rate per
> > senderdomain/server pair?
>
> I was thinking larger, but lets take the 100
> msg/second example if you wish

A 100 msg/s outbound rate from a _single_ server
does not leave room for thinking larger. Use as
many servers as you need.

> While many messages will pass from one server to
> another quickly, the standard is to retry
> delivery on failed nodes for up to 5 days and
> since you don't know if end-user MTA is directly
> connected or not, nor do you know how many extra
> nodes the message would go through, you will
> have to keep this data for at least 5 days as
> well.
> So we have:
> 1. Necessity to update dns zone 100 times per second
> 2. Necessity to keep 100*60(1 min)*60(1 hour)*24(1 day)*5=43,200,000
> (that is 43 million) records in one dns zone file
> 3. Each record requires about extra 100bytes (as from your example) in
> dns zone, based on above the size of dns zone file will grow up to
> 5GB in size. That is far too large to allow to to be transmitted
> through DNSSec

That's almost exactly what it is proposed in the
MBA draft, but for a 10 day period instead of 5.

> > The larger the DomainKey key size, the greater
> > the reason to use MBA instead.
>
> Logical argument does not work that way. MBA is
> not the only choice here as alternative, nor
> does greater key size mean domainkey would not
> work.  It just speaks on that DomaiKey should
> use different key size. 768-bit consumes
> 100bytes in 7-bit translation. 100bytes is
> acceptable for dns record and leaves space for
> dnssec key in same 512k packet if necessary.
> And if somebody wants more then 768bit key, we
> can design it so that record is split among two
> or more dns records still allowing for dns udp
> to work.

It was not said MBA was the only choice. It was
not said DomainKeys would not work. 

MBA is just competing with DomainKeys, disputing
what was once stated about it not even coming
close.

> > > 3. Using entire message with headers for
> > > calculating hash is bad idea because headers
> > > often change in transmission and sometimes
> > > even message.
> >
> > MBA signs only the message body.
>
> Good for you. And so does PGP and S/MIME but
> they do it the "right way" that is consistant
> with email standards.

DomainKeys and MBA operate at MTA level. PGP,
S/MIME don't.

It can be hard for large providers to force all
its customers (and all the customers's mailing
peers) to deploy PGP too.

> > > For reliable operations, content of the
> > > message needs to have its own signature for
> > > each mime portion has and separate one for
> > > headers, listing which ones are being used.
> >
> > MBA assumes a single singnature covering the
> > whole body is cost-effective enough for the
> > spam problem.
>
> Which is where it fails, the intermediate MTAs
> wishing to add content can and should be able to
> add additional mime content data.

I disagree arbitrary changes to message body fit
into the role of a intermediate mailer.

> > > possibly change it. And although personally
> > > I don't think intermedita MTA should be
> > > changing content, the real life is that many
> > > mail lists do (for example all isp-lists.com
> > > maillists to which I subscribe) and add
> > > additional maillist identification
> > > information to the buttom of the message so
> > > even getting rid of the message if content
> > > does not verify would not work.
> >
> > MBA is not broken by most commonly found
> > message body changes.
>
> No, actually it would be broken by "most
> commonly found message body changes" just like
> every other system relaying on signature for
> entire body.

Ok. MBA does support some very limited kinds of
body changes, though.

> > The intermediate mailer has options:
> >
> > - Not to change the message body at all.
> > - Change and resign the message body.
> > - Change the message body wildly without
> > resigning, breaking verification. Such behavior
> > is broken. If the intermediate MTA wants to be
> > friendly to verification-aware final MTAs, it
> > will stop disrupting messages.
> >
> > Message verification proposals must not be
> > evaluated according broken mailers. Better fix
> 
> These mailers are not broken in the current
> email system. They are widely used for
> maillists, forarding systems, etc. Any proposal
> should be flexible enough to accomdate existing
> infrastructure and not require immeidate upgrade
> of entire system in order to be able to use it
> or take advantage of it.  This was all discussed
> in the begging of ASRG back in May 2003.

How widely used a thing is does not affect its
brokenness. If message body changing by intermediate
mailers is a bad thing, this has to be evaluated
outside of any message verification discussion. 

It's just an accident that message body
verification brings to attention how improper to
disrupt a message body is.

It's very important not to require upgrade of the
entire system. That's why MBA does not require
upgrade of every intermediate mailer. Intermediate
mailers don't even need to implement MBA. They
just have to stop disrupting message bodies, or
abide to re-sign the message by using MBA
themselves.

> BTW - This is kind-of stupid that I have to be
> the one to point to Everton that he's wrong to
> think his system would work.

MBA works. The real questions are: Is MBA better
than DomainKeys in the general case? What about
special cases? Are these options the best we have
for message verification?

> I'm actually in support for message tracking
> verification and was the one that introduced
> this concept when ASRG started and have offered
> several ways it could be done properly. However
> people felt that it has no chance of being
> usable in real world because of the requirements
> to keep data tracking info about each message
> that passed through the system and that makes it
> too costs for implementation (I personally think
> 5GB database for 100msg/sec is not too large and
> can be implemented, although obviously not with
> DNS).

It's not obvious it won't work with DNS.

It's possible that it will not support high update
rates with DNS because current DNS software was
not built with support for high update rates as
requirement.

> Since I'm not hearing any other objects to
> Everton, maybe others now think it can work and
> it is actually cost-effective way to stop spam,
> in that case I'll be happy to work on the
> practical implementation that does not have the
> same problems as dns, and allows for quick
> expiration of the messages and removal if next
> MTA in the path appropriate protocol for such
> system should most likely be based on message
> tracking (see MSGTRK working group documents)
> although using UDP for quicker data
> retreival/confirmation is not bad idea either.

You don't need a protocol for message removal,
unless you want to support undue message body
changes by intermediate mailers.

Other than this, I'm all for it.

-- 
Everton




______________________________________________________________________

Yahoo! Messenger - Fale com seus amigos online. Instale agora! 
http://br.download.yahoo.com/messenger/

_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg