From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
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.
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.
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.
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.
For some reason the market does not seem to be too keen on that idea.
I don't think they will want MAPS as their root either.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html