Subject: [ietf-dkim] Delegation semantics

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Aug 2006 08:50:01 -0700

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:   [email-masked]
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=[email-masked]"
			"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=[email-masked]"
			"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.

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

---

From: John Levine <[email-masked]>
Date: 29 Aug 2006 16:30:27 -0000

>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.

Mailers routinely delegate subdomains to their ESPs right now.  For
example:

$ dig email.orbitz.com ns

; <<>> DiG 9.3.1 <<>> email.orbitz.com ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49736
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;email.orbitz.com.              IN      NS

;; ANSWER SECTION:
email.orbitz.com.       16536   IN      NS      bb1dns1.edc.dartmail.net.
email.orbitz.com.       16536   IN      NS      bb1dns2.ddc.dartmail.net.
email.orbitz.com.       16536   IN      NS      bb1dns3.ddc.dartmail.net.
email.orbitz.com.       16536   IN      NS      bb1dns1.ddc.dartmail.net.

R's,
John

---

From: <[email-masked]>
Date: Tue, 29 Aug 2006 12:46:17 -0400

http://www.mxlogic.com/emaildefense/comprehensive_protection.html?GCID=S
16104x002&KEYWORD=mx%20logic
these folks make a living by using delegated namespace.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Levine
Sent: Tuesday, August 29, 2006 12:30 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Delegation semantics

;; QUESTION SECTION:
;email.orbitz.com.              IN      NS

;; ANSWER SECTION:
email.orbitz.com.       16536   IN      NS
bb1dns1.edc.dartmail.net.
email.orbitz.com.       16536   IN      NS
bb1dns2.ddc.dartmail.net.
email.orbitz.com.       16536   IN      NS
bb1dns3.ddc.dartmail.net.
email.orbitz.com.       16536   IN      NS
bb1dns1.ddc.dartmail.net.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 29 Aug 2006 13:01:10 -0400

Philip,

Off the top of my head, this looks like it will work.  This will provide
also for an optimal single lookup for the low to mid tier market where 1st
party delegation is all that is required.

However, the question remains if what is the policy _association_ with the
legacy x822 headers, in particular when and where there is no signature?

If the verifiers sees just this:

    From: [email-masked]
    To:  [email-masked]
    Date: ....
    Subject: .....

or even include the sender:

    Sender: [email-masked]
    From: [email-masked]
    To:  [email-masked]
    Date: ....
    Subject: .....

Are we going to ignore addressing the highly detectable and thus highly
possible protection in legacy facsimiles of the unsigned message?

Remember, if this remains to be an ignored condition, then bad actors simply
will just avoid mail with signatures good or bad, 1st or 3rd party, what
have you.  All they need to do is simply just broadcast old standard
unsigned mail as they do now.   In this case, we lost a major opportunity to
protect the 1st party domain, the abuse on the receiver system, and also
lost the opportunity to force bad actors to adapt in our direction.

If we conclude there is a value here to extract policy from default legacy
headers, I believe we are in the right direction with your proposal.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>

> ...
> ...
> 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.