Subject: Re: [ietf-dkim] ADSP stats

From: Jeff Macdonald <[email-masked]>
Date: Mon, 2 May 2011 15:06:39 +0000

On Wed, Apr 20, 2011 at 8:29 PM, Murray S. Kucherawy <[email-masked]> wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
>> Sent: Wednesday, April 20, 2011 1:25 PM
>> To: [email-masked]
>> Subject: Re: [ietf-dkim] ADSP stats
>>
>> On Apr 20, 2011, at 4:36, <[email-masked]> wrote:
>>
>> > Indeed lack of support for 3rd party signers was where I gave up any
>> > interest at all in adsp
>>
>> As I remember it, there was (or appeared to be) consensus to get ADSP
>> out there for testing by the entities it might work for, AND
>> simultaneously work on something for the 3rd party scenarios.
>>
>> What ever happened to that work? I know there were a couple of drafts,
>> and Murray added support for one to OpenDKIM...if the 3rd party stuff
>> is really that important, why isn't anyone using it?
>
> Indeed, I asked this question at a couple of industry trade groups I attend, MAAWG being one of them.  The answer I generally get is that the key delegation already supported by DKIM works just fine, so why do we need some other mechanism that hits the DNS yet again and employs some complex policy expression language?

Sorry I'm late to the party. Perhaps it it just me, but I think when
talking third-party, folks could be talking about two different
things.

1) Key delegation, as Murray mentions. I believe this means when the
party that authors the message uses a third party to send the message.
The first party delegates the signing domain to the third party*. I
agree that there doesn't need to be another mechanism to do such
things.

2) The RFC5322FromDomain doesn't match DKIM's d= parameter. This means
that a RFC5322From of example.com and a d= of
transactional.example.com is considered third party.

> There has been no uptake at all in OpenDKIM for ATPS, and almost none is apparent with ADSP

I can see ATPS gaining momentum in two ways:

a) ADSP adopts it to allow third party signing (using the definition
from #2 above)
b) an author wants to assert a relationship with a DKIM signer.

I see b being useless for receivers. I believe the RFC5322FromDomain
should never match the d= parameter.

* many ESPs do not do DNS delegation, but instead simply generate key
pairs for their clients and have clients put the public key in DNS.

-- 
Jeff Macdonald
Ayer, MA

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 May 2011 09:33:19 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
> Sent: Monday, May 02, 2011 8:07 AM

I think (b) might be useful if the receiver does something like VBR or a reputation query about the third-party.  But if there's no apparent need for a third-party mechanism, then we're pretty much done.

> pairs for their clients and have clients put the public key in DNS.

I include that mechanism when I say "key delegation" as a mechanism for authorizing a third party, so maybe we need a better general term.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 2 May 2011 12:27:31 -0700

> I include that mechanism when I say "key delegation" as a mechanism for authorizing a third party, so maybe we need a better general term.

Perhaps "key exchange" would fit?  In any case, it sure sounds like we need a dedicated BCP about this so we can stop having to re-explain it every other week.

(This is not a call for rechartering the DKIM WG.)

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions