Subject: [ietf-dkim] The mystery of third party signatures

From: John Levine <[email-masked]>
Date: 6 Oct 2009 00:38:18 -0000

>In light of the comments by Bill Oxley and my belief that the ability of
>a domain to designate signing by a specified 3rd party is useful, ...

It would really be helpful if you two could explain WHY you think it's
useful.  Given the way that DKIM works, there's only two possible
benefits from third party signatures.  Say we want to have isp.com
signing for its customer a.com:

A) a.com sends its mail through isp.com's system, a.com is unable to
sign mail before it's relayed to the smarthost, and it's too hard for
isp.com to apply an a.com signature

B) Nobody's heard of a.com, so it wants to benefit from the reputation
of isp.com.

If you can't tell us which of these you have in mind, we're just going
to go around in circles.  I don't think there's any other problem that
DKIM signatures can solve, but if you disagree, please tell us what it
is.

R's,
John
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 6 Oct 2009 13:44:36 -0400

> C) I can sell the ability to do 3rd party DKIM signing for those companies who are described in A)

Oh, OK, so what we need is better DNS provisioning tools.  Problem solved, 
as far as the IETF is concerned.

R's,
John

> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of John Levine [[email-masked]]
> Sent: Monday, October 05, 2009 8:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ietf-dkim]  The mystery of third party signatures
>

---

From: Doug Otis <[email-masked]>
Date: Tue, 06 Oct 2009 11:47:48 -0700

> isp.com to apply an a.com signature

While it is possible for a.com to implement DKIM signing on their 
servers, they may not able to allow their roaming users access to their 
email server that resides behind a firewall access point.  It is even 
possible that a.com's ISP does not allow them to operate an externally 
accessible server as stipulated in their SLA.

As a result, a.com might wish to utilize the services of isp.com that 
signs with DKIM, and confirms a user's control of an email address 
before signing whenever the From header is not within the isp.com's 
domain.  This works fine until it comes time for policy to be applied.

> B) Nobody's heard of a.com, so it wants to benefit from the reputation

Unfortunately, that too is a valid reason for taking advantage of a 
larger providers size.

Also add-

C) To authorize mailing lists to better ensure their message's handling 
while asserting a policy of "all".

> DKIM signatures can solve, but if you disagree, please tell us what it

An exchange of keys or selectors via CNAME records represents an 
unnecessary expense when compared to a unilateral 
base32(sha1(authorized-domain)) label published below the _adsp 
subdomain.  To ensure against collision concerns, the name of the 
intended domain can be also included within the resource records as well 
as the domains policies regarding this domain.

Such as:

_HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp._domainkey.example.com.
  IN TXT "tpa=isp.com; scope=F;"

This authorization scheme would not require isp.com to change how they 
currently handle their email or sign with DKIM.  Such an authorization 
scheme scales and could better ensure the handling of messages from 
mailing lists, when more stringent policies are being applied.

-Doug

---

From: <[email-masked]>
Date: Tue, 6 Oct 2009 13:30:13 -0400

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Oct 2009 13:46:57 -0700

> C) I can sell the ability to do 3rd party DKIM signing for those companies who are described in A)

If you're getting paid for signing somebody else's traffic, doesn't
it make sense that the service can do some hand holding to get their
DNS set up correctly? In fact, if you're handling their DNS too
-- which seems likely on average -- what exactly is the problem?

Mike

---

From: Doug Otis <[email-masked]>
Date: Tue, 06 Oct 2009 15:38:37 -0700

> -- which seems likely on average -- what exactly is the problem?

Your option of helping each customer publish a public key or a CNAME 
reference to a public key in their DNS also requires ongoing maintenance 
when keys roll over.  It would also mean messages signed by third-party 
DKIM providers will appear "as if" signed by their customer's domain 
rather than by an authorized provider's domain.  In addition, for each 
of these messages, specific selectors and domains need to be inserted 
into each customer's message.

A simple and static hashed "authentication" record could be applied by 
customers at their leisure _without_ modifying how third-party DKIM 
providers sign their customer's email.  Use of a hashed authentication 
record allows all messages to receive the same signature, where there 
would be no transitioning concerns with respect to when a customer's DNS 
server synchronized with that of the provider's key references.

Extracting cost for this service could occur when allowing customers the 
use of their own domain in From headers.  After that, no hand holding or 
DNS publication coordination would be required.  Another benefit could 
include an easy ability to authorize mailing-lists that modify messages. 
  Such authorizations could be added and removed without affecting the 
operation of the outbound MTA or the mailing list.

-Doug

---

From: Daniel Black <[email-masked]>
Date: Wed, 7 Oct 2009 20:10:11 +1100

On Wednesday 07 October 2009 09:38:37 Doug Otis wrote:

Doug,

I've in favour of a solution to option C) as you describe it: To authorize 
mailing lists to better ensure their message's handling while asserting a 
(ADSP) policy of "all".

Publishing third party allow records on the author domains seems to be the 
most reliable method here.

A simplified record syntax of the following could be used:
mipassoc.org._3p._domainkey.example.com IN TXT "dkim={all|unknown|discard}"

advantages:
* simple
* DNS can be delegated at the _3p level (or any level below)
* same format as ADSP (needed at least dkim= to avoid conflicts with all 
wildcard SPF record)
* could apply mail-filtering same as ADSP (only stricter)

disadvantages:
* cannot do full mailbox [email-masked] (don't know if this is needed)

far left side benefits:
A list archive like gmane or mailarchive could publish a DNS hierarchy in the 
same form as a service to verifiers who want the answer to the question "Is 
this a email list?"

> providers sign their customer's email.
good

> Use of a hashed authentication
> record allows all messages to receive the same signature,
I don't know what this means.

> where there would be no transitioning concerns with respect to when a 
customer's DNS server synchronized with that of the provider's key references.
good.
> operation of the outbound MTA or the mailing list.
good goal.

Daniel Black

---

From: Doug Otis <[email-masked]>
Date: Wed, 07 Oct 2009 10:30:52 -0700

On 10/7/09 2:10 AM, Daniel Black wrote:
> I've in favour of a solution to option C) as you describe it: To
> authorize mailing lists to better ensure their message's handling
> while asserting a (ADSP) policy of "all".
>
> Publishing third party allow records on the author domains seems to
> be the most reliable method here.
>

Daniel,

A DNS label is limited to containing 255 label characters which includes
a length byte for every label.  In your example of a simple domain
reference, this has used 41 bytes.  Subtracting the fixed labels, this
leaves a remainder of 240 bytes to specify both domains.  In some
regions, the TLD and SLD labels have come rather long, especially when
using ACE (puny code) labels.  As an alternative, the hash example only
consumes 32 characters for the authorized domain.

Using the simply label approach, the maximal domain length supported
requires that all maximal domain sizes be below 120 characters.  This
limit is needed to constrain the resulting reference to 15 +
authorized-domain-length + authorizing-domain-length to the maximum
domain length. Which means in essence, maximum domain length MUST remain
well below 120 characters before the simple approach is assured to function.

As DNS evolves into encoding non-ASCII character strings, and with
perhaps a growing competition for TLDs which will mean these too will
grow in length and will be encoding international character sets, a
maximal limit imposed by the "simple label" approach seems certain of
avoiding trouble.

The hash approach only requires that the authorizing domain occupy less
than 204 characters, as opposed to all maximal domains being less than
120 for 170 increase in available space.  In the last draft that
proposed this message, it contributed C code for a command line function
that generates the hash labels using standard libraries.

> advantages: * simple * DNS can be delegated at the _3p level (or any
> level below) * same format as ADSP (needed at least dkim= to avoid
> conflicts with all wildcard SPF record) * could apply mail-filtering
> same as ADSP (only stricter)
>
> disadvantages: * cannot do full mailbox [email-masked] (don't
> know if this is needed)

That was what the g= parameter within the DKIM key was intended to
resolve.  Clearly, authorized third-party domains should be expected to
perform this level of screening instead.

> far left side benefits: A list archive like gmane or mailarchive
> could publish a DNS hierarchy in the same form as a service to
> verifiers who want the answer to the question "Is this a email
> list?"

Agreed. Perhaps this could include a policy assertion about the nature 
of the third-party domain.

>> A simple and static hashed "authentication" record could be applied
>> by customers at their leisure _without_ modifying how third-party
>> DKIM providers sign their customer's email.
>
> good
>
>> Use of a hashed authentication record allows all messages to
>> receive the same signature,
>

Sorry.  I meant the same signature key reference.  In other words, no
change needs to be made in how messages are signed and which keys are used.

>> where there would be no transitioning concerns with respect to when
>> a customer's DNS server synchronized with that of the provider's
>> key references.

> good.
>
>> Extracting cost for this service could occur when allowing
>> customers the use of their own domain in From headers.  After that,
>> no hand holding or DNS publication coordination would be required.
>> Another benefit could include an easy ability to authorize
>> mailing-lists that modify messages. Such authorizations could be
>> added and removed without affecting the operation of the outbound
>> MTA or the mailing list.
>
> good goal.

On that we agree.

-Doug