Subject: [ietf-dkim] TXT Subdomain queries

From: Hector Santos <[email-masked]>
Date: Tue, 05 Jun 2007 14:11:24 -0400

I'm not DNS Administrator expert, but I did a small exploration in two 
possible ways to deal with sub-domains.

I'm using the DSAP draft syntax to illustrate this

Method one:  Multiple TXT records:

_dsap  0   TXT "v=dsap1.0; sd=*; rr=0; op=optional; 3p=never;
                   a=rsa-sha256; fa=fail; fx=fail; fs=fail;

_dsap  0   TXT "v=dsap1.0; sd=corp; rr=0; op=always; 3p=never;
                   a=rsa-sha256;

_dsap  0   TXT "v=dsap1.0; sd=sales; rr=0; op=always; 3p=never;
                   a=rsa-sha256;

_dsap  0   TXT "v=dsap1.0; sd=europe.sales; rr=0; op=always; 3p=never;
                   a=rsa-sha256;

_dsap  0   TXT "v=dsap1.0; sd=public; rr=0; op=never; 3p=never;

_dsap  0   TXT "v=dsap1.0; sd=list; rr=0; op=never; 3p=optional;
                   3pl=mipassoc.org

Give a domain with any number of subdomains, if any, take the main 
domain and preface with _DSAP to do a TXT lookup.

For example:  sales.isdgn.net

  NSLOOKUP -query=txt _dsap.isdg.net

Non-authoritative answer:

_dsap.isdg.net  text =

         "v=dsap1.0; sd=public; rr=0; op=never; 3p=never;"

_dsap.isdg.net  text =

         "v=dsap1.0; sd=corp; rr=0; op=always; 3p=never; a=rsa-sha256;"

_dsap.isdg.net  text =

         "v=dsap1.0; sd=sales; rr=0; op=always; 3p=never; a=rsa-sha256;"

_dsap.isdg.net  text =

         "v=dsap1.0; sd=list; rr=0; op=never; 3p=optional;
            3pl=mipassoc.org"

_dsap.isdg.net  text =

         "v=dsap1.0; sd=europe.sales; rr=0; op=always; 3p=never;
            a=rsa-sha256;"

_dsap.isdg.net  text =

         "v=dsap1.0; sd=*; rr=0; op=optional; 3p=never;
            a=rsa-sha256; fa=fail; fx=fail; fs=fail;"

In this case, the SD=sales subdomain tag is found to expose the domain 
policy.

Method Two: Using Wildcards

In this case, its better to use the ZONE setup for this:

*._ssp      0   TXT "v=dsap1.0; rr=0; op=; 3p=; fa=fail; fx=fail;
                        fs=fail;

_ssp        0   TXT "v=dsap1.0; sd=*; rr=0; op=optional; 3p=never;
                        a=rsa-sha256; fa=fail; fx=fail; fs=fail;

corp._ssp   0   TXT "v=dsap1.0; sd=corp; rr=0; op=always; 3p=never;
                        a=rsa-sha256;

sales._ssp  0   TXT "v=dsap1.0; sd=sales; rr=0; op=always; 3p=never;
                        a=rsa-sha256;

europe._ssp 0   TXT "v=dsap1.0; sd=europe.sales; rr=0; op=always;
                        3p=never; a=rsa-sha256;

public._ssp 0   TXT "v=dsap1.0; sd=public; rr=0; op=never; 3p=never;

list._ssp   0   TXT "v=dsap1.0; sd=list; rr=0; op=never; 3p=optional;
                        3pl=mipassoc.org

In this case, a lookup for sales._ssp.isdg.net will provide the record 
we want.   If it was missing, then the first record is return.

So a lookup,  NSLOOKUP -QUERY=TEXT   foobar._ssp.isdg.net will yield:

     "v=dsap1.0; rr=0; op=; 3p=; fa=fail; fx=fail; fs=fail;

Which says NO MAIL expected for this domain!

What are the problems with this type of logic?

-- 
Sincerely

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

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Wed, 06 Jun 2007 23:38:31 -0700

> In this case, the SD=sales subdomain tag is found to expose the domain

Two issues:

When you receive a message from sales.idsg.net, how do you know that the
"main" domain is idsg.net?  More generally, if you get a message from
covington.losaltos.k12.ca.us, what is the "main" domain?

Returning a whole bunch of TXT records doesn't scale at all well to
large numbers of subdomains.
> What are the problems with this type of logic?

Again, the difficulty, if you receive a message from sales.idsg.net, is
knowing where to query.  Is it sales._ssp.idsg.net, or
_ssp.sales.idsg.net?  More complex domain names will result in more
possibilities.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 04:49:44 -0400

> _ssp.sales.idsg.net?  More complex domain names will result in more

I see.

But why not define it so its always two levels, isdg.net? and let the 
zone define the rest?

Maybe a solution would be to use the main domain to obtain a record that 
"instructs" the client to what is the the "main domain?"

Also, if DNS can't handle the representation of complex unions, then why 
not just go to a TXT result syntax that provides a masking concept and 
let the client perform this task all in single line?  Ala SPF-like 
directives?

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Jun 2007 10:15:55 -0700

> But why not define it so its always two levels, isdg.net? and let the
But it's not always two levels:  I gave one example for that in
.k12.ca.us, but there's also .co.uk, .edu.au, and too many other
examples to enumerate.  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.
>
> Maybe a solution would be to use the main domain to obtain a record
> that "instructs" the client to what is the the "main domain?"
>
> Also, if DNS can't handle the representation of complex unions, then
> why not just go to a TXT result syntax that provides a masking concept
> and let the client perform this task all in single line?  Ala SPF-like
> directives?

I'm not sure what you mean here.  Discovery of the TXT record and
retrieval from the right place would still be a problem.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Jun 2007 15:31:21 -0400

> examples to enumerate.  

Ok. How is the zone file defined?

     whatever.edu.au

If this is a problem and it seems no one here knows hows to address it, 
it sounds to me the WHOLE domain is the only recourse.

> retrieval from the right place would still be a problem.

Well, then if this is a ISSUE then there is only one SOLUTION - use the 
whole domain as provided by the email address.

And then within this TXT record, it can provide a wildcard, MASKING 
syntax, if required, to represent subdomains.

It just sounds to me that if this 2 vs 3 zone, and cuts is getting in 
the way, then we need to go with POSSIBLE today and then see if it can 
be optimized later.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Jun 2007 14:50:16 -0700

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