[ietf-dkim] TXT Subdomain queries

[Douglas Otis]

On Jun 7, 2007, at 10:15 AM, Jim Fenton wrote:

> Doug Otis has proposed that a registry of such names be maintained,  
> which I doubt would be workable, and in any case wouldn't cover sub- 
> delegation.  And we have already discussed the problems with  
> associating semantics with zone cuts; there are administratively  
> separate domains in common zones, and subdomains under common  
> administration in separate zones.

To prevent DKIM from substantially increasing DNS DDoS risks, avoid  
having recipients performing domain transversals or placing reliance  
upon the use of wildcard resource records.  So what is left?


1) Domain transversal can be limited by registering with IANA a  
fairly static list of registry domains.  This would contain about  
1000 domains and indicate which are being used by registries for the  
purpose of publishing other domains.

DKIM already assumes that a parent domain is authoritative, where  
such a list at least satisfies the last minute requirement added by  
IESG.  Any second or third level domain used by a registry would have  
an incentive to ensure that their domains are entered into the list.   
The traffic generated by all the unterminated queries will provide  
the enticement without needing any other means of encouragement or  
legal obligation.

Such a list also reduces caching and network overhead related to  
retrieving domain related behavior information.  Just information  
related to the principal domain (the domain just below the registry  
domain) often satisfies recipient's needs.  Bad-actors tend to  
utilize wildcard domain labels and attempt to flood these systems.


2) Anchor policy to the MX and A records (where the use of the A  
record is deprecated).  Future protocols would be encouraged to  
define a DNS specific RR to establish a protocol "proof of existence".

An anchor approach would preclude domains that are being phished from  
also using wildcard MX records.  Any domain being phished is well  
advised to not utilize wildcard MX records anyway.

Using this approach, policy records would only need to be placed  
adjacent to any MX or A record.  Eventually policy would only be  
placed adjacent to MX records, once A records in a discovery process  
have been finally obsoleted.  Even placement adjacent to A records  
represents far fewer entries than that needed to establish a  
functional wildcard for the same purpose.

Email represents a rather special case.  Email is a protocol pushing  
data without prior arrangements.  It is doubtful other protocols  
would be best served by a wildcard scheme.  Most other protocols  
utilize a pull mechanism where policy requirements are significantly  
different.  In a pull protocol, policy is more easily handled within  
the protocol without risking exposure to wildcard DDoS exploits.


3) Out of band policy publications.

Such policies as well as accreditations could be created by:

  - the end-users leveraging their address-book,
  - by social networks that construct sets of lists,
  - by accreditation services.

Out-of-band policy publications could play a role in protecting other  
resources beyond just email, such as blogs, and IM applications as well.

--------

The policy records should also be able to authorize SMTP clients,  
SMTP MAILFROMS, and third-party signers.  Domain association offers a  
proactive means to curtail replay or back-scatter abuse, and  
establish a reasonable means to administer Inter-Domain associations  
via a single transaction without prior arrangements.

Once policy can be located quickly by using either strategy #1 or #2,  
then adding a prefix hash of the associated domains to policy can  
scale without incurring more than one additional transaction.

	_dkim-all TXT "<email related policies (xyz also available)>"

   (xyz:)
	<hash>._dkim_mf TXT "<mail-from related policy>" relates DKIM domain  
hash to email-address
	<hash>._dkim_s TXT "<sender related policy>" relates DKIM domain  
hash to email-address
	<hash>._dkim_f TXT "<from related policy>" relates DKIM domain hash  
to email-address
	<hash>._dkim_c TXT "<client related policy>" relates SMTP client  
hash to DKIM domain.

-Doug