On Jun 16, 2006, at 7:34 AM, Hallam-Baker, Phillip wrote:
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
In addition to usurping the use of the PTR record, this solution
requires placement of a wildcard domain name containing a PTR RR at
every label. DNSsec indicates the synthesized labels needed for
checking the signature. Complete coverage with wildcard domain names
will tend to expose existing labels. This seems rather impractical.
Not that this appears to be practical, rather than usurping the PTR
record, perhaps a CNAME might be a practical solution.
See:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-
clarify-11.txt
-------
3.3.3 Type Matching
RFC 1034 concludes part 'c' with this:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
#
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
The final paragraph covers the role of the QTYPE in the lookup
process.
Based on implementation feedback and similarities between step
'a' and step 'c' a change to this passage has been made.
The change is to add the following text to step 'c' prior to the
instructions to "go to step 6":
If the data at the source of synthesis is a CNAME, and
QTYPE doesn't match CNAME, copy the CNAME RR into the
answer section of the response changing the owner name
to the QNAME, change QNAME to the canonical name in the
CNAME RR, and go back to step 1.
------
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.
Agree on both points.
You mentioned the use of a URL, but to what type of server?
HTTP, all else is noise.
RFC2821 meets RFC2616. : )
Is the response determined by a specific URI namespace? Overlooking
zone delegations, as DKIM currently does, it also seems this service
might also define sub-zone policies and develop a parallel
structure. : O
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.
Would you care to elaborate? Provided the underlying services are
not altered, confirmation of a newer version being offered by the
signing domain remains possible. Lacking this confirmation should
impose some type of warning, and under no circumstance should a
deprecated version be accepted without the presence of a non-
deprecated version from the same signing domain. While not perfect,
this should prevent a downgrade attack where both the signing and
verifying domain have upgraded. Once the verifier is upgraded to
understand the new service, the warning is removed. These types of
warnings should motivate an upgrade or act as a valuable alert
without adding any additional dependencies.
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.
Blocking ads is exciting? At least there is a clearer imperative
when blocking phish.
From our efforts, this seems to be an overstatement. Once a trusted
list provision becomes part of an email message annotation
application, whether at the MUA or MTA, there are several
organizations likely willing to contribute. Perhaps organizations
such as the APWG would be a good starting point.
Much better to give network admins the tools to describe their
policy themselves than this bizare ad-hoc scheme you are proposing.
An ad-hoc list from a trusted community could still greatly assist
the network admin with this otherwise tedious task. : )
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html