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

[William Leibzon <william at completewhois.com>]

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.
 
> > (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

> 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)

> > 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
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

Based on above I do not believe DNS is capable of being used for such 
purposes, nor would anybody else who has been a dns administrator nor
would the people who designed dns (feel free to ask them on dnsext or
dnsop WG mailing lists).

> > 2. The 348-byte key size used for Yahoo domain
> > keys is too weak and that means message can too
> > easily be forged. Key size should be increased
> > to 512 bytes or preferably 768 bytes.
> 
> 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.
 
> > 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.

> > 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.

> > 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. 

> > Since we can not trust message that passed
> > through intermediate system to still carry valid
> > domainkeys singnature it opens the system up to
> > abuse.  All spammers have to do is to add some
> > random yahoo domain keys signature to the
> > message and add additional forged received
> > header to make it seem that message passed
> > through non-compliant mail list or forwarding
> > system that change the original. In such case,
> > eventhough message still has yahoo domain keys
> > signature, it can not be used for verification
> > and as such the message could have been forged
> > but we really don't know for sure eventhough
> > domainkeys signature is present.
> 
> 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.


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. 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).
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.

---
William Leibzon
william at completewhois.com


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