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