ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue #1265: Signing by parent domains

2006-05-26 18:22:42

On May 26, 2006, at 5:06 PM, Paul Hoffman wrote:

It doesn't matter how good or bad the maintainer of the higher- level domain is: all that matters is what the signer puts in d=. If i=doug(_at_)mail-abuse(_dot_)org and d=mail-abuse.org, then it makes not a whit of difference what the key policies and so on of .org are because the verifier will never look there.

Stated another way, what part of "This is the domain that will be queried for the public key" has anything to do with the DNS hierarchy?


Here is a different example:

A message is signed with the following:

... i=somebody(_at_)some-domain(_dot_)co(_dot_)uk d=some-domain.co.uk

Here, as with your example, there is no assertion that the d= domain is authoritative for some sub-domain.


versus

... i=somebody(_at_)some-domain(_dot_)co(_dot_)uk d=co.uk

Currently this is permitted in the base draft which indicates the parent domain is authoritative for sub-domains.


Assume co.uk included DNS entries to support an MTA that handle messages with email-addresses:

<local-part>@co.uk

where their signature might normally contain:

... i=somebody(_at_)co(_dot_)uk d=co.uk

or perhaps just

... d=co.uk

With the (baseless) assertion that any parent domain is authoritative for any sub-domain, their MTA systems might be mercilessly attacked until compromised in a number of ways. Once accomplished, bad-actors could then spoof messages with any email-addresses that contained *.co.uk when parent signing is considered a means to verify sub- domain email-addresses (to get the gold-star annotation perhaps). Once bad-actors compromise just one key held at co.uk, the impact of this breach extends well beyond the co.uk domain. By not permitting the assertion allowing any parent domain to be authoritative for sub- domain email-addresses, any breach would remain isolated to the domain where the key is located, as you suggested. This requires a change to the draft.

-Doug




_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

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