> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Todd Lyons > Sent: Tuesday, September 21, 2010 8:07 PM > To: Hector Santos > Cc: [email protected] > 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 [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
