[ietf-dkim] draft-ietf-dkim-base-02 // Parent signing security
dotis at mail-abuse.org
Thu Jun 1 12:54:10 PDT 2006
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
> - 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
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
> - 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
> 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.
More information about the ietf-dkim