ietf-dkim
[Top] [All Lists]

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

2007-06-06 15:57:22

On Jun 6, 2007, at 3:01 PM, Hector Santos wrote:

Jon Callas wrote:

In short -- saying "I sign everything" with a non-existent or bogus key is the same thing as saying, "You'll never see a valid one of these."

The problem is DKIM-BASE mandate of

      'IGNORE FAILURES'

This results in a poor solution.

A bad-actor is free to include email-addresses from any sub-domain and even reference an existing key selector located within some higher domain. Neither the recipient nor the domain owner are able to mitigate damage created by added cryptographic challenges or the flood of queries for non-existent records.

Unless SMTP is changed to demand that a domain publish an MX record as "proof or existence", there remains a need to declare which domains should be excluded from being processed.

Neither SPF nor MX Dot offer a safe solution for this assertion. Phillips XPTR is also unlikely to be safe or easily deployed. The DKIM WG should not punt and then assume there is a safe solution. DKIM will increase the overhead associated with spoofing at virtually no cost to the bad-actor. The DKIM WG should offer a solution for mitigating a likely problem DKIM exacerbates.

By having an implicit "NO MAIL" policy as the original SSP specs had as well as DSAP, it clearly marked the very strong policy concept of what the DOMAIN expected.

In other words, saying "I signed Everything", failed mail does not protect the domain from a exploited domain that should had NEVER been used in the first place.

Agreed.

If we are willing to fold the failed "I signed Everything" transactions, as a clear rejectable transaction, then you are right. It can work, but it a WEAKER statement with some "possibility" for false positive. With a NO-MAIL policy, you have 100% NO FALSE positives.

Requiring existence of an MX record with an exception granted by an interim period that allows A records would be another solution.

-Doug

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

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