dkim-ops
[Top] [All Lists]

Re: [dkim-ops] DKIM - ATPS

2010-09-24 11:08:37
Jeff Macdonald wrote:

So I personally do not think this will be an issue.

I've seen it, with SPF records. A client may support TCP, but if the
firewall is set to not allow TCP packets for DNS, then you will have
the same issue.

So this issue exists. I'm getting support questions related to this
about once a quarter, up from once a year.

Yes, I have seen it too, but mostly with home tier gateways or bugs. 
The point is in a modern operation, in lieu of bugs, the modern DNS 
client/server needs to do it properly and DNS servers respond accordingly.

I've seen a customer report where our AVS mail bot w/ SPF worked fine 
from the company network installation but not from his private home 
setup.  In the end, it was a bug in our DNS resolver that had an 
uninitialized "UseTCP" setup variable hence random intermittent 
non-zero (true) values.  Apparently his home tier gateway DNS proxy 
was immediately closing the port 53 TCP request.  We confirmed it by 
having him set the setup to use primary DNS server ip and not the 
default PC DNS name servers.  It worked fine.  So fixing this resolved 
his gateway DNS server not allowing TCP.

Again, my only point was that for the complexity we are dealing with, 
we can't depend a DNS solution where we thinks bugs or low end setups 
that do not support a DNS streaming protocol properly as show stoppers.

When the DNS client starts with UDP and fall back to TCP when the UDP 
response contains a truncated datagram, I have not seen issues.

That said, I am not advocating this is the way to go. It needs to be 
explored which is what we are doing and from a product standpoint we 
offer the options to see what works for people.

Both ATPS and ASL are implemented for exploration. I personally prefer 
ASL before its more management and more "packed" with information 
providing a payoff with a DNS query.

If there is a 255 per domain length issue with this, there would be a 
length issue in general. A domain using hugh length proper will see 
other problems. Why would one use such an impractical ergonomics huge 
length for their users?  Sure its theoretically bound, but its 
impractical to see such huge length domains.

Regarding ATPS, its already been proven that MD5 can be clobbered with 
collision attacks which means you can get two equal hashes for two 
different domains.

            http://en.wikipedia.org/wiki/MD5#Security

To suggest the odds are low, is the same arguments for lengths being 
very high.

Also, a MD5 is 32 characters.  That would be a fixed amount for all 
domains.  That means this can potentially add a higher storage 
requirement in DNS.

Using Pareto's Principle, most domains will not be 32 characters or 
greater.  So even given the two, you have more storage efficiency with 
using the literal than the fixed 32 bytes MD5 hash.

Hence, I am not convince it is better because:

    1) Its harder to manage, requires more tools, enforces key manager
       frontends than a simple text editor,

    2) Adds a predictable greater size requirement than the average,

    3) MD5 has proven collision issues.

Again, that is my opinion.   We added both extensions so we will see 
how people go with this.  The fact is, for ATPS, we had to give them a 
MakeATPS.exe hashing tool. Something you don't need for ASL.  Plus, 
already, we had to add comments as values to help with the management 
at this point.  For example, dig the ATPS for gmail.com for our 
winserver.com domain:

   nslookup -query=txt 
f74d39fa044aa309eaea14b9f57fe79c._atps.winserver.com

   Non-authoritative answer:
   f74d39fa044aa309eaea14b9f57fe79c._atps.winserver.com    text =

         "v=atps1; d=gmail.com;"

So that would be one suggest for Murray to add a "MAY" add a value for 
their own management purposes.  He should give his reasons which it 
lowers the security bar for "Layman" hackers, but certainly it doesn't 
nothing to stop the determine hacker who simply needs to look at a 
DKIM-Signature d=domain and author-domain he wishes to exploit using 
some sort of MITM DNS exploit.

For now, simplicity to work out the logistics.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops

<Prev in Thread] Current Thread [Next in Thread>