From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
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.
Read the draft. It solves every requirement
The DNS wildcard mechanism is not defined in a manner that is ideal for the
type of administration we need.
Changing the DNS protocol is outside scope, changing the DNS infrastructure is
something we have done already.
Plenty of people change the DNS infrastructure, Paul Vixie did it when he
deployed his spam blacklist hack.
You mentioned the use of a
URL, but to what type of server?
HTTP, all else is noise.
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.
You don't understand the issue.
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.
Community projects don't do boring jobs. What you propose would be tedious
beyond description.
Much better to give network admins the tools to describe their policy
themselves than this bizare ad-hoc scheme you are proposing.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html