[ietf-dkim] Delegation semantics

[Hallam-Baker, Phillip]

I think that the NS suggestion is a bad one for policy reasons. I am never going to delegate any part of my DNS. Space to a third party and I don't think anyone else is likely to either. I think that there are much simpler and easier ways to skin this cat.

The problem is that there is no way for me to delegate any part of my key space without allowing the delegatee absolute control and the ability to impersonate any sender in my domain that they choose.

Lets stop talking about NS records for a moment and consider the semantics that we actually want in the delegated signing case. In particular to what extent do we want the fact of delegation to be visible to verifiers?
 
Lets have some parties:
 
Party claiming responsibility for content:   alice at example.com
Party that has the signature key:            remailer.com


1) Completely opaque delegation

Alice does not need to allow the world to know that the messages are actually going to be signed at remailer.com. All she needs to do to allow this is to simply insert the relevant key record in her zone:

remailerkey._domainkey.example.com  TXT "key=423249671234986u3hf89713ty49y=="

If we are using dynamic DNS update we can automate this process using existing standards.


2) Transparent delegation

Alice may want the world to know that there is a delgation relationship in place and in particular she may want to retain control of the delegation relationship.

This speaks to a need for TWO selector records, one in example.com and one in remailer.com. The example.com selector needs to state that remailer.com is allowed to sign for a particular email sender, the remailer.com selector needs to contain the actual key. The effective selector record is the composite of the two.

Lets get away from the DKIM ulta compact syntax for a moment and write the attribute tags out longhand:

remailerkey._domainkey.example.com  TXT 
			"sender=alice at example.com"
			"include=examplecomkey._domainkey.remailer.com"

examplecomkey._domainkey.remailer.com TXT "key=423249671234986u3hf89713ty49y=="

The DKIM header contains the selector remailerkey.


What we have here is a delegation mechanism that works but would require us to rejig base. We can avoid this by putting the reference into the remailer policy record (this is cleaner for legacy deployments as well):

remailerkey._domainkey.example.com  TXT 
			"sender=alice at example.com"
			"delegate=**.remailer.com"

examplecomkey._domainkey.remailer.com TXT 
			"authority=remailerkey._domainkey.example.com"
			"key=423249671234986u3hf89713ty49y=="

In this case we have very explicit statements of the form 'here I am delegating authority to X' and 'here I am claiming a grant of delegated authority'. The delegation relationship is transparent. This approach is also more flexible than the scheme above since we delegate the power to define keys.


We have successfully achieved both types of delegation semantics without recourse to any additional DNS feature and without doing damage to the DNS semantics. We are much less likely to face unexpected interactions.