dkim-ops
[Top] [All Lists]

Re: [dkim-ops] DKIM Testing Feedback Loops

2010-09-22 02:15:08
-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org 
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Todd Lyons
Sent: Tuesday, September 21, 2010 8:07 PM
To: Hector Santos
Cc: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] DKIM Testing Feedback Loops

The site DKIM Verifier implementation now has ADSP support with my R&D
on the ADSP extension ASL (Allow Signer List) idea.  We are now
Example ADSP record for winserver.com:
dkim=all; asl=mipassoc.org,megabytecoffee.com,
              mapurdy.com.au,santronics.com,isdg.net

I see very quickly the potential for scaling problems.  What's your
expected max length?  DNS TXT records can consist of 255 byte strings,
so if your length is more than 255 characters, you'll have to split it
into multiple strings (upper bound of any DNS record seems to be
65535).  Personally, I subscribe to 43 different mailing lists.  For
someone like me, I think you'll have to consider doing like spf where
you can include other txt records for the asl setting in order for it
to scale.

Splitting into multiple strings isn't a hindrance really.  That's what we do in 
DKIM with large public keys.  You'd just need to stipulate that multiple 
"character-strings" as DNS calls them are concatenated before parsing the 
resulting payload.

I think this proposal and others like it sidestep the scaling problem with the 
argument that this isn't intended for a large domain (gmail.com, for example) 
to list all of the domains that host lists to which its users subscribe, but 
only specific high-value phish domains like the popular paypal.com example.  In 
that case they're probably right that it's unlikely such a domain would make an 
ASL that's very big or very dynamic and it would probably continue to fit 
inside a UDP reply, but it also constrains that approach to a very small slice 
of the signing population.  (Then again, that's who ADSP was for...)

Given the two, I prefer the TPA approach at least in terms of how to store the 
data in the DNS so that it can be easily queried.  It makes the authorized 
third-party signer list much more extensible and furthermore enables 
specification of policies or other details for each signer without adding more 
payload to a single common record.  However, TPA as currently presented suffers 
a little from being overly complex without any data to justify that complexity.

It's still not even clear that there will be a widespread need for this kind of 
DKIM-related technology or that its value trumps that of other related work 
like domain reputation and use of VBR, but nevertheless since so many people 
are certain this is going to be necessary for long-term success of DKIM, it 
seems that some real experimentation is warranted.

I've taken the liberty of producing a trimmed-down TPA concept called ATPS 
which, if implemented, would be an ADSP extension.  It's up for review here:

http://www.ietf.org/id/draft-kucherawy-dkim-atps-00.txt

I'll take a run at coding up an extension to OpenDKIM to do this for its next 
major release after the current Beta wraps up.  We can then use the statistics 
portion of OpenDKIM to monitor deployment and gather some results, though as I 
think I said before it could be many months before we know anything.  Other 
implementers are of course invited to collaborate on implementations and the 
collection of data.

Comments welcome.

-MSK


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