ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-base-02 // Parent signing security considerations

2006-06-01 13:01:05

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

<Prev in Thread] Current Thread [Next in Thread>