At 10:19 AM -0700 6/1/06, Douglas Otis wrote:
: 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.
This has many technical flaws that would need to be addressed before
we put anything like it in the base spec. Taken sentence by sentence:
- This is not about TLDs. As many people have pointed out earlier, it
affects all levels of delegation. This includes the root. As long as
we are considering implausible security threats, we should remember
that ICANN might put _domainkey in the root, put a key there, then
have it compromised in a way that threatens all DKIM users.
- Even if the second sentence is true (and I doubt anyone here has
done the research to say whether or not it is), it is misleading. It
is just fine if a higher-level zone publishes a key: it is only bad
if that key is compromised.
- The third sentence is misleading unless you change "can be
constructed" to "can be constructed by an attacker who has
compromised the higher-level's key and then sends out mail signed
with the compromised key during the period before the higher-leve's
key is still being distributed".
- The fourth sentence needs to define the "harm". That will help
readers understand just how little threat there is. It might also
cause the WG to decide that this threat is so insignificant that it
doesn't need to be listed in the document.
- The fifth sentence is false. There is lots of other protection
available, namely the fact that the compromised key can be replaced
as soon as the attacker starts using it.
- The sixth sentence is false in that it is not the simplest remedy.
ICANN has fewer than 10% of all of the TLDs in the root under
contract, which makes this change anything but simple. A simpler
remedy would be for people in lower-level zone who discover an
unexpected key in a higher-level to complain and possibly shame the
owner of the higher-level key to stop publishing it.
If the WG thinks that this is a credible threat, the proposed
paragraph should be changed to deal with these issues before we
consider it for inclusion in the base draft.
NOTE WELL: This list operates according to