ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: draft-dkim-pcon

2006-06-15 23:01:25

On Jun 15, 2006, at 6:32 PM, Hallam-Baker, Phillip wrote:

From: Douglas Otis

A common policy record used with many applications also seems unlikely to fit within a 512 byte DNS message constraint, and imposing a linking script is highly reckless from a security standpoint.

Clearly there needs to be a means of securing referenced content but that is a well understood problem. A URL plus a digest of the linked content for example.

The idea of a URL concept exists within the CERT RR and seems to be a reasonable extension that might be included within the key, for example. Would you agree, as it currently stands, a wildcard is not practical for ensuring any sub-zone has a policy? Changing the way DNS works also seems out of scope for this WG.


It seems a new policy service is really needed, rather than new DNS policy resource records or new methods for handling wildcards. What existing server would be suitable? LDAPv3 (RFC3377) referenced from the email-address domain SRV record?

It would appear that your proposal would by your own definition be highly reckless.

There might be a method that exposes a limited portion of the information in read only form. You may have not noticed the question marks. This was asking for your take on what would be a suitable server, as DNS appears ill suited for publishing the amount of data required for many applications within a common record. Attaching appendages at each label also transforms a label tree into a directory structure, which is why LDAP came to mind. You mentioned the use of a URL, but to what type of server?


DKIM provides a valuable service without attempting to accommodate per-user policies via DNS. The down-grade attack affecting S/MIME et al, can be avoided by incorporating a version "deprecation" ('d') flag.

No it can't. The attacker can strip out the signature entirely.

A message with only a deprecated signature should be considered not signed, thus any non-deprecated signature "striped out" would nullify a deprecated signature. Once both signer and verifier upgrade, the downgrade attack is eliminated. Until the verifier upgrades, a down grade attack is not an issue. Messages with a signature using an unknown service should be marked with a red flag.


Lists of trusted signing domains replace a need to separately discover a less meaningful domain policy records. Bad actors are just as capable at publishing policy records. A trusted list avoids look-alike domain attacks and excessive traffic hunting for sporadically published records. Trusted list also offer a safe basis for annotating messages. It seems that mechanisms for accessing trusted lists (an element or extension of the address book) within applications protocols such as IMAP would be more productive extending the value of the DKIM signature.

This mechanism is already possible today, just make ldap.verisign.com your root for downloading policy data.

This was not a suggestion for that type of service. Of the millions of domains, a relatively small percentage of transactional domains are being attacked. A community effort similar to http:// adblock.mozdev.org/ could construct a user modifiable list of popular transactional domains. A user could include less popular domains confirmed by a pass-phrase from web-site using a certificate, while avoiding a need for this effort in the majority of cases. As an alternative, this could also become an extension of the address book that annotates messages based upon a list of signing domains. The address book could be setup by way of an LDAP server, within a corporate network. A policy record offered by a bad actor might indicate any number of hoops an email-address must jump through. An obstacle course offers little in the way of protection, once signed messages become the norm for trusted transactions. A list of popular transactional domains offers proactive protections without expensive surveillance and similar domain acquisitions. Little else seems needed. Guidance with respect to what is normal for the signing domain could be included within or adjacent to the key.

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

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