On Jun 1, 2006, at 12:28 PM, Paul Hoffman wrote:
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.
There are prohibitions against delegating a domain with the
underscore. That prohibition may preclude seeing a _domainkey label
at the root. I also doubt that a DKIM verifier would accept d=; as a
valid domain.
- 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.
There are broader implications regarding who is authoritative as
well. From a quick review, the general limitations relevant to DKIM
appear to be within RFC1591.
- 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".
Where the system of the TLD is compromised does not seem all that
relevant. Perhaps this could be modified to say "constructed by a
bad actor" ?
- 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 harm of a compromised key is already defined in the threat draft
as having a high impact. I am not happy with the threat draft
definition of impact. Even so, perhaps harm could be replaced with
"a high impact" ?
- 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.
This assumes the nature of the exploit and who will replace the key.
The effected party may have no business relationship with TLD
provider other than a domain delegation. How will the affected party
learn of the exploit in a timely manner? There would be no server
activity that could be used as an alert.
- 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 TLD finds this to be a new revenue source, shame may not be
enough however.
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.
Of course, the WG must decide on the language, but this should still
be included within the security consideration section.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html