ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt

2007-07-06 10:26:14

On Jul 5, 2007, at 2:25 PM, Jim Fenton wrote:

I have seen a few comments on the list, in particular Phillip's comment about the downgrade attack that we need to discuss more. If any of you are holding onto comments, please go ahead.

While Phillip is correct about the downgrade issue, the key record would need to be modified instead of an SSP record. The SSP record is only checked when the message is not signed by a domain that is at or above the email address domain.

I'm particularly interested in reactions to the algorithm given in section 4.4.

The only way to provide full coverage without dramatically increasing the zone size would be to ensure an SSP record coincides with every SMTP discovery record (MX and A). Deprecation of the A for discovery now should exclude use of AAAA records from becoming a problem. Over time, A record discovery could be obsoleted where SSP records would only need to coincide with MX records. The A record discovery aspect of SMTP would become obsolete once a MX record for an email-address domain becomes a requisite for message acceptance at public SMTP servers. A record discovery could continue to function with the sending of messages well after A record discovery becomes deemed obsolete to support a acceptance requirement. This would mean a email-address domain lacking an MX record might have trouble sending their messages, where some are already finding this to be the current state.

This is another attempt to strike the right balance between security (the SHOULD for subdomain coverage in SSP requirements section 5.1 #4), ease of deployment (trying to avoid doubling the size of zones with extra SSP records), and avoiding creation of unacceptable loads on DNS, and root and TLD name servers in particular. Speak up if there are any uncovered holes in this algorithm, or where I haven't achieved these goals.

Little is achieved by using wildcards. Wildcard synthesis blocking within the DNS protocol necessitates placement of both a wildcard and non-wildcard RRs at every DNS node. As an alternative, establishing tighter conventions upon discovery records actually reduces the amount of data published within DNS. Limited discovery also requires fewer DNS transactions, and can be a broadly applied strategy for other protocols. It would also mean that the current strategy of prefixed TXT records can be utilized.

Deploying a new wildcard XPTR scheme will necessitate increasing the zone size. The XPTR scheme requires additional transactions which will likely to return NXDOMAIN for many years. Those that fear a new RR might not be supported will also need to support an alternative method as well. Unless this alternative depends upon a limited discovery record, such as MX or SRV records, the size of the zone could grow exponentially larger as other protocols attempt the same strategy. Limiting discovery records is really the only reasonable solution for any protocol attempting to establish policy records.

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