Subject: [ietf-dkim] Update to draft-otis-dkim-tpa-label-04

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jun 2010 12:37:11 -0700

The following draft has been updated and submitted.  It references the 
dkim-mailinglist draft and the APWG Trend report.

Scopes now only indicate what headers must be included by an authorized 
third-party service, or as an interim strategy, what path related 
elements can be used when DKIM signatures are not offered by the desired 
third-party service.

http://www.ietf.org/id/draft-otis-dkim-tpa-label-04.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-04.html

-Doug

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

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 22 Jun 2010 17:47:46 -0400

> http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-04.html

Doug I stopped reading at section 3.2. I think this is too ambitious.
But I want some of this functionality. What I'd like is a draft like
this that doesn't require any dkim changes. I also don't want it tied
to ADSP. I see an alternate definition of 3rd party. It seems the
definition in this draft doesn't call this a 3rd party:

DKIM-Signature: ... d=foo.example.net
From: [email-masked]

I think some folks say it is.

A simplification of this draft would be:

1) if the signature validates
    a) create a label composed of <d=>._tpa.<author-domain>

So for the above, one would do a DNS lookup at:

foo.example.net._tpa.example.net

if there is a record, there is a stated relationship between
<author-domain> (example.net) and <d=> (foo.example.net).

I'll read the rest of your draft, but I'm wondering if my
simplification would be enough for most folks. IMHO any service that
builds off of DKIM should do something like this. It would reduce the
need for multiple signatures.

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2010 16:10:41 -0700

On 6/22/10 2:47 PM, Jeff Macdonald wrote:
> On Mon, Jun 21, 2010 at 3:37 PM, Douglas Otis<[email-masked]>  wrote:
>    
Hey Jeff,
> this that doesn't require any dkim changes.
Ahem.  This draft does not require _any_ changes to DKIM, and only 
appends to values placed in the ADSP dkim tag.

By doing so, this provides a restrictive assertion able to reject 
messages lacking an Author Domain, or that have not been authorized, or 
that don't include specified headers.
> I also don't want it tied
Per the draft,

      2.2.2.  Third Party Signature

A "Third Party Signature" is a Valid Signature that does not qualify as 
a Author Domain Signature.

An author domain must exactly match with the From domain.

A tpa-label for foo.example.net within the example.net domain allows
  DKIM-Signature: ... d=foo.example.net
to be considered equivalent to an author signature of d=example.net.

This would allow From: [email-masked] to be signed by DKIM-Signature: 
... d=foo.example.net.  Importantly, when there is no valid 
author-domain signature or authorized third-party, the message should be 
refused.  This changes "dkim=all" into providing a clearly actionable 
result. :^)

The tpa-label scheme also provides a set of scopes to require a header 
added (i.e. sender or list-id) that contains the domain of 
"foo.example.net".  This is to provide a mechanism for recipients to 
isolate messages by using available sorting tools.  This scheme also 
handles authorizing third-party services that don't use DKIM, but offer 
a means to confirm EHLO, or the return-path.  Hopefully, such allowances 
would only be an interim solution.  The hash label also prevents anyone 
from walking this list, assuming you might want to limit the information 
to those with a need to know.

>      a) create a label composed of<d=>._tpa.<author-domain>
>    
The simpler approach was not used in favor of a scheme able to handle 
large domain names.  We have yet to see the extent of international 
domain names that start at the root, with several wanting to construct 
foreign phrases.  Look at some of the top level domains used by the 
French, as a possible clue for where this lead once this also includes 
the use of ACE-labels (or a-labels for short).  This scheme also places 
all authorizations into a single zone with less DNS related interaction 
and faster lookup.    The chance of collision for 3 x 10^45 domain names 
is less than 0.1%.
> foo.example.net._tpa.example.net
Yes, this is fine, provided domain names constrain themselves to using 
less than half of whats allowed.  The tpa-label approach using a hash 
label reduces the maximal domain name size by 6%, and ensures consistent 
response accommodations where listed domains can be wildcarded or not 
listed as needed.  Causing too large of a response might cause difficult 
to resolve because resource record allocations changes per domain.
> <author-domain>  (example.net) and<d=>  (foo.example.net).
>
I hope to be working with the OpenDKIM group to include these functions 
in an experimental version.  The code needed to generate tpa-labels is 
already written.  I am talking to my employer about creating a general 
purpose _tpa. zone that others could delegate or use with DNAME to 
access a list of safe third-party services.  More sensitive domains will 
likely want to publish their own _tpa list.  The nature of these 
services might dictate inclusion of List-Id or Sender headers.

Just imagine.  By using this scheme, anyone using a large DKIM signing 
provider that allows use of a customer's From email-addresses (that 
check ownership first), could then tightly restrict acceptance of their 
messages while still being able to participate in mailing lists, or use 
other email providers without needing to share DKIM key information.  A 
restriction that the large provider would be unlikely to impose. Your 
customers could do it, and it would just work. That is where things need 
to be remain simple.

I noticed a few typos and others have indicated a few missing bits on 
the last draft.  A minor update will be published soon.

-Doug