There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high
level domain. This could be viewed as an ICANN, ARIN, APNIC, LACNIC,
AfricNIC, RIPE NCC, and DENIC consideration advice. RFC1591 makes
the following statement:
,---
| There are no requirements on subdomains of top-level domains
| beyond the requirements on higher-level domains themselves. That
| is, the requirements in this memo are applied recursively. In
| particular, all subdomains shall be allowed to operate their own
| domain name servers, providing in them whatever information the
| subdomain manager sees fit (as long as it is true and correct).
'___
There did appear to be some consensus this could be viewed as
requiring contractual rather than technical considerations. This
requirement should be indicated within the security consideration
section at least.
: Security Considerations:
:
: Keys published by common higher-level domains
:
: Although TLD managers are trustees for the delegated domain, DKIM
: introduces a security concern unrelated to domain delegation.
: Registry Operator Functional Specification Agreements normally
: preclude registering "_domainkey" due to the underscore character.
: This limitation is expected to also preclude TLD managers from
: publishing the "_domainkey" label as a subdomain. There are also
: unsanctioned alternative TLD managers and SLDs managers operating
: under a variety agreements known to include domains exceeding
: normally prescribed characters.
:
: By utilizing the unqualified subdomains of the DKIM-Signature
: header field 'i=' parameter, a DKIM key can be referenced
: from any higher level domain to validate an email-address
: containing these subdomains. This provision might be exploited
: to usurp the validation of an email-addresses of a lower domain.
: As a result, DKIM keys published at a higher level could expose
: subdomains to harm from a possible security breach at a higher
: level and to conflicts with regard to what is a valid
: email-address. For example, the key's 'g=' localpart template
: provision permitting MUA signing does not restrict the
: subdomains that can be included within the DKIM-Signature 'i='
: parameter.
:
: Unless otherwise already preclude by existing agreements, a
: DKIM operator will need to establish separate agreements
: governing the high-level domain's covenants as related to the
: specific use of the "_domainkey" subdomain. These new functional
: requirements should include limitations on key retention periods,
: key sizes, the handling of the private key, and whether
: address validation assertions are permitted within lower
: level domains.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html