Thanks Doug,
Douglas Otis wrote:
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.
: Currently there are no contractual obligations barring gTLD, ccTLD,
: or SLD managers from publishing DKIM accessible keys within a
: "_domainkey" sub-domain. While this sub-domain can not be
: delegated as a domain due to the underscore character '_',
: unqualified sub-domains in the 'i=' parameter can be constructed
: to reference a key published by a higher level domain. These
: higher level keys expose all sub-domains to harm from a possible
: security breach at these higher levels. The only protection
: available to owners of all sub-domains would be established
: contractual obligations that currently do not exist. The simplest
: remedy would be to ban inclusion of any sub-domain beginning with
: the underscore '_' within these common higher-level domains.
-Doug
Eliot, can you raise this as a new issue as discussed at the
jabbering today?
Ta,
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
