Subject: [ietf-dkim] Possible issue with Parent Domain logic in SSP

From: <[email-masked]>
Date: Tue, 8 Jan 2008 18:14:46 +0000

I was rereading the validation algorithm last night and came across something that is either a good reason not to read these drafts at night, or a potential problem for some deployments. Among the companies I have worked with over the years it is fairly common practice to allocate a subdomain to some external party who manages some service for you. For example if you have transactional mails which you want to come from your domain but are actually managed by some third party who does billing for you you might point the NS record for billing.example.com to the third party so that they can manage the MX for that domain, the website, etc... 
    In reading the verification algorithm, since it assumes an SSP record is intended to cover not only the domain in the Originator address but also the parent of that domain this seems like it would create an issue for companies in this situation. Basically to enable these companies to create a STRICT record for their top level domain, they now need to be able to make assurances about something that is not directly in their control, specifically about a domain that they created with the specific intent that it be managed by someone else.

So if I am bank.com and have a significant problem with misuse of that exact domain and want to use SSP to help mitigate that risk but I have allocated a subdomain to some third part (say thirdparty.bank.com) it looks like my choices come down to
1) Publish SSP with dkim=unknown until thirdparty creates their own SSP record for thirdparty.bank.com
2) Take thirdparty.bank.com back from thirdparty and manage the DNS for whatever services they provide myself
3) Publish ssp with dkim=strict and let mail for thirdparty fail to be validated

I understand the operation efficiency that is created by assuming that a record for a parent domain covers its immediate subdomains but assuming that the practices of one domain apply to another seems like it may create some issues for the quality of those practice assertions.

Hopefully I have read this wrong or someone has a better solution than the three I outlined above.

Robert

_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008

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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 08 Jan 2008 10:34:27 -0800

[email-masked] wrote:
>     I was rereading the validation algorithm last night and came
> across something that is either a good reason not to read these drafts
> at night, or a potential problem for some deployments. Among the
> companies I have worked with over the years it is fairly common
> practice to allocate a subdomain to some external party who manages
> some service for you. For example if you have transactional mails
> which you want to come from your domain but are actually managed by
> some third party who does billing for you you might point the NS
> record for billing.example.com to the third party so that they can
> manage the MX for that domain, the website, etc...
>     In reading the verification algorithm, since it assumes an SSP
> record is intended to cover not only the domain in the Originator
> address but also the parent of that domain this seems like it would
> create an issue for companies in this situation. Basically to enable
> these companies to create a STRICT record for their top level domain,
> they now need to be able to make assurances about something that is
> not directly in their control, specifically about a domain that they
> created with the specific intent that it be managed by someone else.

Actually, it's the other direction:  an SSP record can cover not only
the domain it's published in, but also immediate child domains.  But you
have the rest of this right.
>
> So if I am bank.com and have a significant problem with misuse of that
> exact domain and want to use SSP to help mitigate that risk but I have
> allocated a subdomain to some third part (say thirdparty.bank.com) it
> looks like my choices come down to
> 2) Take thirdparty.bank.com back from thirdparty and manage the DNS
> for whatever services they provide myself

There's a fourth option that is designed to cover exactly this case:

4) Publish ssp with dkim=strict and t=s and it will not apply to
subdomains like thirdparty.bank.com.

Of course, when you do this, it applies to all subdomains (and
hostnames), not just thirdparty.

Does this address your concern?

-Jim

---

From: <[email-masked]>
Date: Tue, 8 Jan 2008 18:55:49 +0000

> Date: Tue, 8 Jan 2008 10:34:27 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [ietf-dkim] Possible issue with Parent Domain logic in SSP
> 

> Does this address your concern?
 Yes, I think it does. Not sure how I missed that step. 

Thanks,

Robert

_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 9 Jan 2008 10:28:53 +0100

Jim Fenton wrote:
 
> Publish ssp with dkim=strict and t=s and it will not apply to

Good t=s example, something like it in the draft would be nice.
I risk a "RTFM, already there" without checking for this... ;-)

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 09 Jan 2008 11:33:01 -0000

> hostnames), not just thirdparty.

But can't you publish a full strict SSP for example.com, and also a  
separate not-so-strict SSP for billing.example.com? Or am I missing  
something? But that does mean you need to be able to say 'unknown'.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 9 Jan 2008 13:37:25 +0100

Charles Lindsey wrote:

> that does mean you need to be able to say 'unknown'.

Interesting, now I finally understand the purpose of
"unknown", it allows to override a parent strict SSP
without a global t=s affecting all subdomains.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Wed, 09 Jan 2008 07:20:40 -0800

> something? But that does mean you need to be able to say 'unknown'.

Yes, that works too, but it was implied in the original question that
the subdomain hadn't [yet] published an SSP record for the subdomain.

-Jim