Subject: [ietf-dkim] Meta (was: ISSUE: Modify ADSP Lookup Procedure)

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 1 Jun 2008 18:11:20 +0200

Eliot Lear wrote:

> Just an fyi to all, the issue tracker is down with no estimate
> on its repair.  I will be working this week to recover open 
> issues.

Thanks for info.  Apparently new IETF WGs now automatically get 
"trac" (wiki, roadmap, tracker, etc.), but are of course not
forced to use it, e.g. <http://tools.ietf.org/wg/idnabis/trac>

DKIM doesn't have this yet, but I guess you could request it on
the "tools" list if you want it (temporarily, or to replace RT).

 Frank

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jun 2008 15:18:37 -0700

Dave Crocker wrote:
> Modify ADSP Domain Existence procedure.
> 
> Use draft-levine-dkim-adsp-00, Section 4.3. ADSP Lookup Procedure as input to 
> discussions.

Per the Levine draft, this also entails addition of:

      <section anchor="applicability" title="ADSP Applicability">
         <t> ADSP as defined in this document is bound to DNS. For this reason,
           ADSP is applicable only to Author Domains with appropriate DNS
           records (see Note below). The handling of other Author Domains is
           outside the scope of this document. However, attackers may use such
           domain names in a deliberate attempt to sidestep an organization's
           ADSP policy statements. It is up to the ADSP verifier implementation
           to return an appropriate error result for Author Domains outside the
           scope of ADSP. <list style="hanging">
             <t hangText="Note:  "> The results from DNS queries that are
               intended to validate a domain name unavoidably approximate
               the set of Author Domains that can appear in legitimate email.
               For example, a DNS A record could belong to a device that does
               not even have an email implementation. It is up to the verifier
               to decide what degree of approximation is acceptable.</t>

to the Section 3. Operation Overview.

d/
-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jun 2008 15:47:53 -0700

> to the Section 3. Operation Overview.

At least part of this (what attackers might do) reads like a Security 
Consideration, and perhaps belongs there instead.

I'd like to suggest that we use a different word than "approximate" in 
the above discussion and in the Levine draft.  "Approximate" may give 
the impression that the error may be in either direction, i.e., that 
there may be some legitimate email domains may be considered out of 
scope for ADSP.  How about something like "overestimate" instead?  (Note 
that I'm not considering a hostname like wjvax.UUCP to be a legitimate 
mail domain any more).

-Jim

---

From: John Levine <[email-masked]>
Date: 5 Jun 2008 19:57:24 -0000

>the above discussion and in the Levine draft.

I wasn't thrilled by "approximate", but I couldn't think of a word
that more accurately captured what I was trying to say.

> "Approximate" may give the impression that the error may be in
> either direction, ...

Depending on local configurations, there might be.  My MTA is set up
so that it recognizes domains for local hackery that aren't visible in
the DNS.  I realize this is out of the scope of 2821, but my thought
was that there's nothing short of trying to deliver the mail and
seeing what bounces to accurately tell what's valid.

I suppose that "overapproximate" would be OK within the constraints of
2821.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Jun 2008 20:52:26 -0700

John Levine wrote:

FWIW, I'm not thrilled with my suggestion either.

Surely we don't need to capture local hacks in the draft.

I can definitely live with "approximate".  I don't think
"overapproximate" is even a word, or if it is, it may mean something
else so let's avoid that one.

-Jim

---

From: [email-masked] (Wietse Venema)
Date: Fri, 6 Jun 2008 10:06:10 -0400 (EDT)

> Note:  The results from DNS queries that are
...
> the above discussion and in the Levine draft.
...
> I suppose that "overapproximate" would be OK within the constraints of
...
> I can definitely live with "approximate".&nbsp; I don't think

This (over)approximation issue is confusing, and it can be eliminated
with a more precise definition of what domains are "in scope for ADSP".

After writing the text that evolved into what's in the Levine draft,
my thoughts have evolved towards the following:

ADSP as defined in [ADSP] is bound to DNS.  For this reason, ADSP
is applicable only to Author Domains with explicit ADSP DNS records.
The handling of Author Domains without explicit ADSP DNS records
is outside the scope of [ADSP].

However, attackers may use out-of-scope Author Domains in an attempt
to sidestep an organization's explicit ADSP policy statements that
some or all email is signed.  For this reason receivers MUST handle
out-of-scope Author Domains appropriately.

The "ADSP scope" algorithm then simplifies into:

- Receivers MUST look up the DNS MX record for the Author Domain.
  If the lookup completes with error code 3 (NXDOMAIN) the Author
  Domain does not exist in DNS, and therefore it is not possible
  to publish an ADSP record for the Author Domain.  Receivers MUST
  treat such out-of-scope Author Domains as an error.

- Otherwise, the Author Domain exists in DNS, but the organization
  publishes no ADSP record for the domain.  Receivers SHOULD resolve
  the domain as required by [SMTP].  If the domain does not resolve,
  receivers SHOULD treat such out-of-scope Author Domains as an
  error.

- Otherwise, receivers MAY treat such out-of-scope Author Domains
  as if the organization had published an explicit ADSP policy
  statement of "unknown".

So the algorithm simplifies into:  MUST do NXDOMAIN test for MX
lookup, SHOULD resolve the domain per [SMTP]. Whether it's SHOULD
or MAY (or even not at all) depends on a trade-off between the
predictability of receiver behavior against typical overhead and
the potential for abuse in packet multiplication attacks.

	Wietse

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 6 Jun 2008 17:46:23 +0200

Jim Fenton wrote:
   
> "overapproximate" is even a word, or if it is, it may mean
> something else so let's avoid that one.

How about "minimal approximation" ?  Proposed text:

| A minimal approximation of a complete "nomailfqdn" check as
| specified in [2821bis] section x.y is an NXDOMAIN (rcode 3) 
| result for a domain lookup, see [RFC 103?] section a.b.

RFC 1034 or 1035, I'm too lazy to find the relevant sections.

 Frank