Subject: [ietf-dkim] Delegation and Designation (#1360)

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Sep 2006 22:19:12 -0700

This is to continue discussion of a topic that came up in today's jabber
chat regarding the need for "designation".  See
http://www.ietf.org/meetings/ietf-logs/dkim/2006-09-28.html from
11:17:47 through 11:30:09.

Let start with some definitions (sorry they're so legalistic; an
"entity" might be a person (user) or domain):

Delegation:  The process of publishing a public key controlled by
another entity, to allow that entity to sign messages for some or all
addresses in your domain.

Designation:  The process of publishing some information that tells a
verifier that signatures from certain external entities ought to be
treated as "first-party" signatures coming from your domain.

Delegation exists in the key management model described in -base.  The
question here is whether we need designation as well.

If I recall correctly, designation arose as a simpler way of doing
delegation.  If example.com wants to use exampletwo.com to send some
mail on its behalf, it merely publishes an assertion (mechanism TBD)
that says that exampletwo.com is a designated signer.  All signatures
from exampletwo.com are considered as valid as those from example.com
for messages with an example.com origination address.

In order to do this by key delegation, example.com would need to obtain
a public key from exampletwo.com and publish it in its own DNS.  This
transfer might need to be secured to make sure that the right public key
gets published.  Then exampletwo.com would need to see when it is
signing messages for example.com and use the right selector and
d=example.com.  When key rotations happen, further coordination between
the domains would be needed.

One use case that was discussed for the g= tag in the key record (which
restricts key validity to address local parts that match a pattern) is
that it allows delegation of keys for only a specific address or
addresses, e.g., [email-masked].  This, in effect, lowers the amount
of trust that example.com needs to have for exampletwo.com, which tends
to facilitate the transaction (since they can't produce signatures for
[email-masked]).  Designation, however, affects the entire domain.

Another issue is that the signatures are different.  In the delegation
case, d=example.com; with designation, it would be d=exampletwo.com. 
While defining anything having to do with how reputation services
operate is outside the DKIM WG charter, it is likely that such services
would use the d= value as a base.  So the difference is significant for
users of DKIM signatures, and simply viewing designation as a simpler
way of doing delegation is erroneous.

So the question is, do we need both delegation and designation?

My opinion, if it isn't already obvious from the above discussion, is
that designation is a flawed way of delegating signing authority.  I
don't like the fact that example.com can hire exampletwo.com to send out
a bunch of bulk advertising, and then when there are objections,
effectively finger-point and say "Exampletwo did it".  If example.com
wants mail sent by exampletwo.com to be treated as if it came from them
(first-party signature), they should be willing to take responsibility
for it themselves.  If they don't want to take that responsibility, they
should accept that exampletwo.com applies a third-party signature.

-Jim

P.S. to John Levine:  exampletwo.com is available for your domain
collection if you want it!
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 29 Sep 2006 06:04:07 -0000

>a public key from exampletwo.com and publish it in its own DNS.

More likely, example.com will delegate a subzone to exampletwo.com
and let exampletwo handle all of the mechanics.

One possibility would be that they'd delegate something like
email.example.com and exampletwo would do the A and MX as well as the
keys.  Another would be to delegate ex2._domainkey.example.com so they
just manage (some of) the keys.  As I've noted several times, the
first scenario is very typical of large mailers using ESPs, many of
which do DK signing now.

>that designation is a flawed way of delegating signing authority.

Agreed.  The main argument I've heard in favor of designation is that
some outsourced DNS services don't let you insert your own NS records,
which strikes me as a reason to find a better DNS provider, not to
design a protocol around it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Sep 2006 01:25:45 -0700

> should accept that exampletwo.com applies a third-party signature.

The delegation process may be the provider routinely offering public
keys to their customers for publishing at specific locations, or the
customer delegating zones at or below their "_domainkey" label to one or
more providers.  This delegation process represents an undesirable level
of complexity involving a significant amount of detail among several
entities when it can be avoided.

Beyond the complexity, delegation in this manner has other significant
down-sides.  You allude to DKIM being used for reputation, but it
remains conjecture whether a digital signature that does not identify
the SMTP Client, and can not prevent replay abuse is even suitable as a
basis for conventional email reputation.  Trust is a differ matter
discussed further down.

What is not conjecture is that DKIM will facilitate abuse reporting to
the signing domain, and that IP based reputation will remain the
predominate basis for conventional email reputation for sometime.  Here
DKIM allows the provider noise-free abuse feedback.  They are sure to be
informed of damage a customer may be causing to their IP address
reputation.  With DKIM, what is sure to matter is who should be informed
and receiving abuse feedback.  Reputation is likely based upon
unsolicited bulk messages where DKIM offers no assurance of even
indicating who might be at fault.

Another concern is easily as serious is that of trust.  When a provider
does not adequately safeguard account access, or properly secure systems
filled with "other people's private keys," there can be significant
damage created for the email-address domain owner when messages of a
criminal or highly questionable nature receive their signature, while
they have never seen the content or have logs of what and to whom.

As for designation-

The draft that was just published illustrates two different signing
roles can be designated, also accompanied with local-part constraints.
All the same features, but with far less effort.  One role would be that
of a domain only offering valid signatures, but without the
email-address being assured valid.  This would be roughly equivalent to
a signature lacking the 'i=' parameter while still fulfilling an "All
Messages Are Signed" assertion.

Another designated role could operate in virtually the same manner as
that of delegation.  Rather than matching keys with accounts, the
provider would match email-address domains with accounts.  Rather than
establishing a complex delegation process, the account would validate
control of the email-address being used.  This validation process can be
automated and is fairly common in many other applications already.

By using a designation process, the email-address domain owner controls
assertions regarding the validity of the email-address.  A provider
might be used for less critical communications where delivery is of
greater importance.  Consider that DKIM offers scant protections without
annotations.  These annotations should permit the recognition of valid
sources, AND valid email-addresses.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Sep 2006 10:17:36 +0100

So - on the jabber chat we almost established a rough consensus
not to include designation at this point.

If no-one else speaks up either way, I reckon that that's the
only resolution, i.e. we drop designation.

If you do want designation included then say so. If you
don't then similarly, say so.

If we already know what you want, or if you don't know what
you want, or if you don't know what this is about, then please
say nothing:-)

At this stage I think we should all understand the issue
sufficiently well that there's no need for debate - let's
just decide.

S.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 29 Sep 2006 07:11:01 -0700 (PDT)

keep 'designation'
[note: I don't like that naming system, but that is not worth debate]