Subject: [ietf-dkim] New issue: Upward query vs. wildcard publication

From: Jim Fenton <[email-masked]>
Date: Mon, 16 Apr 2007 17:59:23 -0700

Over the past few IETF meetings, I have proposed various methods for
publication and query of DKIM information.  Some of these have
significant problems (for which I apologize) and others have significant
overhead.  The assumption here is that a new RR type is being used, but
there are variations on this that could be done with prefixed TXT
records (although possibly with additional queries, to interpret
NXDOMAIN responses properly). These include:

Option 1: Publish wildcards and "shadow records".  The domain publishing
SSP will need to publish a DKIMP [maybe we should call it SSP?] record
at the domain level, and alongside all other records in the zone (what I
call "shadow records).  This could be done manually, but hopefully tools
will come along that will help this.  If there is a wildcard record in
the zone (such as a wildcard MX), a wildcard DKIMP will need to be
published as well.  No need for a wildcard DKIMP record otherwise.  The
goal here is that, if SSP exists, a query anywhere within the zone will
return either the SSP record or a NXDOMAIN response (never a NODATA).

Option 2: The domain publishing SSP will publish a DKIMP record at the
domain level, and alongside all multiple-level label (e.g., foo.bar) 
records in the zone as well as for any subdomains to which it wishes to
propagate DKIM policy.  If there is a wildcard record in the zone (such
as a wildcard MX), a wildcard DKIMP will need to be published as well. 
If a query results in a NODATA response, the verifier would query the
parent domain (only one level).  If a NODATA response to the parent
domain is received, the message is considered non-suspicious.  Note that
this option hasn't been fully vetted, and may have problems yet.

Option 3: As presented at IETF 68, upward queries would be performed if
a NODATA response is required until the verifier gets to a TLD (or
something that acts like one).

Discussion:  Option 3 is simplest for the publisher, but likely to be
considered unacceptable due to the potentially unbounded querying of
higher-level domains, and possible load on root and/or TLD servers. 
Option 1 is the most compliant with DNS directorate wishes, but probably
requires special tooling (in the form of "meta-wildcards" as proposed by
Phill) in order to be practical for large zones, and is otherwise prone
to error.    Option 1 also requires a new record for every label (e.g.,
hostname) in the zone, so it could add up to a lot of additional
records, although most would probably never be referenced (and would
never occupy cache space).  Option 2 is an attempt at a compromise; is
it workable?

-Jim

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Apr 2007 23:07:54 +0200

Hi Jim,
I'm lost with these DNS considerations.  Your option 3 is apparently
the "CSV method" (or rather the CSV method was an elaborated variant
of a naive tree walk, for starters it never hit the root servers)

Anything using wildcards where they're not already used today could
also run into trouble.  If folks like it anyway I hope they've read
I-D.iab-dns-synthesis-concerns-00

Frank

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Apr 2007 20:31:27 -0700

> of a naive tree walk, for starters it never hit the root servers)

I don't remember offhand how CSV did this.  My algorithm wouldn't
directly hit the root servers either, but might do so indirectly in
resolving some TLDs.  There was specific concern from some people who
ran root servers (or perhaps TLD servers) about the impact of the tree
walk, which I can't say I fully understood.  I would expect subsequent
queries to a parent domain to be satisfied by cached answers, at least
as far as root and/or TLD servers are concerned.
> I-D.iab-dns-synthesis-concerns-00

I wasn't aware of it; but I guess it's new.  Thanks for pointing it out.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Apr 2007 07:04:19 +0200

Jim,

I prefer Option 3.5:

Publish a record at the zone level.  If no other record exists, use 
that.  If that record doesn't exist, stop.  This is a cheap form of 
wildcarding.  it requires at most two queries, which while unpleasant 
for some purists avoids people having to deal with wildcards, which 
themselves are a pain.

Eliot

---

From: John Levine <[email-masked]>
Date: 18 Apr 2007 05:51:56 -0000

>Publish a record at the zone level.

I believe this is known not to work, because clients cannnot reliably
see zone cuts through a DNS cache other than by walking up or down the
tree and looking for the SOA record.  (Caches don't always pass along
the SOA from the additional section since the only useful info there
for normal clients is the TTL which it has anyway.)  I also think
there may be some unpleasantness with glue records.

We went through all of this at great length with CSV and concluded
that the least bad way to do faux wildcards with prefixed names was a
tree climb limited to about five levels and stopping at the TLD or
maybe 2LD.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Tue, 17 Apr 2007 22:51:26 -0700

On Apr 17, 2007, at 10:04 PM, Eliot Lear wrote:

> wildcarding.  it requires at most two queries, which while  
> unpleasant for some purists avoids people having to deal with  
> wildcards, which themselves are a pain.

What's the "zone level", here? (If it was defined upthread, I missed  
it, sorry).

Cheers,
   Steve

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 18 Apr 2007 11:02:10 +0100

> higher-level domains, and possible load on root and/or TLD servers.

So any upward search needs to stop as soon as you find a level with an  
SOA. If you haven't found whatever SSP you were looking for by then, then  
you can assume it doesn't exist.

But, as John points out, SOA records tend not to get cached, so you might  
need to insist on an authoritative response and that places a strain on  
the official name servers for the zone, not to mention the extra lookup  
for the SOA.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Apr 2007 10:30:16 -0400

Jim Fenton wrote:
> I don't remember offhand how CSV did this.  

 From the specification at <http://mipassoc.org/csv>:

> If a domain administrator declares an assertion about all names
> within a domain, the appropriate bit MUST be set in the Port field of
> the CSV-CSA record at the root of the domain for which the assertion
> applies, and MAY be repeated at subdomains of that domain. The
> Explicit bit applies to a domain and all its subdomains. If it is
> repeated in a subdomain it has no effect on the semantics, but it
> might cause a search to stop sooner.
> 
> Domain administrators SHOULD publish records with such assertions in
> the port field at a level no deeper than sixth-level domains, such as
> 
> 
> "_client._smtp.sixth.fifth.fourth.third.second.com"
> 
> since receivers are expected to search no deeper than that, and will
> most likely not find records published for seventh-level or deeper.
> (Receivers will, of course, still query for the weight field at the
> exact level of the EHLO string.)

The key to making this scheme work is that the domain name must exist. 
Bad actors cannot use a non-existent name.  Hence, the owner of the root 
for the organization's domain name (e.g., example.com) can know where to 
place these marker records, below the organization's root.

This approach is, of course, a royal pain, but our feeling was that the 
effort was tractable, within the confines of using an existing record. 
For CSV, the SRV record was specified.

Things change considerable if a new RR is used, since regular DNS 
wildcards come back into consideration.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Apr 2007 10:32:55 -0400

> for some purists avoids people having to deal with wildcards, which 

Given that zones are administrative constructs for use by operators, and 
are not intended to be visible to client DNS activities -- and well 
might not be visible, no matter the intent -- then how does the upward 
tree-walk know when to stop?

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Apr 2007 07:50:11 -0700

> tree-walk know when to stop?

In the general case, it doesn't. However, it's possible that in some
cases where the stars align that the tree walk could be made into a
two message exchange affair. It seems to me that it's worth digging
deeper on this point as it seems like it's actually the common case
that the SOA for a given subdomain is the same as the parent of that
subdomain. Sorry to be a bit vague.. these pages are still getting
swapped back into memory.

		Mike

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Apr 2007 16:50:02 +0200

The resolver would have to construct the query non-recursively.  I agree 
that this is a problem.

Dave Crocker wrote:
> Given that zones are administrative constructs for use by operators, 
> and are not intended to be visible to client DNS activities -- and 
> well might not be visible, no matter the intent -- then how does the 
> upward tree-walk know when to stop?
>
> d/
>
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Apr 2007 10:57:28 -0400

> cases where the stars align 

Horoscopic Internet standards effort?  Horror scope-ic...

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Apr 2007 08:02:20 -0700

> Horoscopic Internet standards effort?  Horror scope-ic...

No, optimization for the normal case, a worse treadmill for the
legal-but-more-unusual case. Note I've actually implemented this
a long time ago. I have never gathered any statistics on what
percentages are "normal" vs. "unusual", but my cursory look a
long time ago suggested that it met the 80-20 rule.

		Mike

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Apr 2007 19:17:00 +0200

> Publish a record at the zone level.

For SPF that option was rejected by Paul Vixie:
<http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00049.html>

After that discussion the "zone cut" idea published
in some SPF drafts was removed again, and RFC 4408
works without it.  For SPF that's no big issue:

Mail claiming to be "mail from [email-masked]"
can be directly rejected (without any SPF magic),
if the domain bar.example.org has no MX and no IP.

Likewise a forged EHLO bar.example.org trying to
send bounces (= empty reverse path) won't survive
modest plausibility checks by a server.

In other words the owner of example.org can ignore
all bogus subdomains like bar.example.org wrt SPF:

Receivers could anyway reject all "mail from" these
constructs.  If they accept the spam and later try
to bounce it this won't work because there's no MX
and no IP.  Smart spammers know this and won't try
to abuse such subdomains, unless they have "better"
reasons to ignore "call back verification" issues.

But for SSP the same reasoning might fail miserably,
because DKIM isn't about "good" vs. "bad" bounces.

Frank