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

[Jim Fenton]

robert at barclayfamily.com 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
> 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

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