Thank you for pointing this out. Based on this information,
does that mean
that any type of anti-spam scheme that relies on the DNS system
(RMX/rDNS/etc.) would be inherently insecure? Also, What
exactly is the
nature of the problem with the current DNS-SEC standard?
I don't believe that the lack of a deployable DNSSEC spec prevents the
deployment of RMX type solutions for the following reasons:
1) DNS Clients can detect spoofing attempts and use them as spamdication.
2) Requests may be made using TCP/IP to achieve additional spoofing
protection.
3) There is no value in securing the DNS system against IP address spoofing
attacks unless the resulting system protects against the same spoofing
attacks in SMTP.
4) If robust cryptographic means are used for authentication these may
employ existing mechanisms for trust path advertisement and discovery (XKMS,
LDAP, HTTP) to advertise security policy.
The problem with the DNSSEC specs as they stand is that deployment has an
immediate effect on the size of a signed zone even if none of the zones
delegated from that zone are actually secured. This means that deployment of
DNSSEC would immediately cause the size of the dotcom zone file to grow from
about 4 Gb to about 24 Gb. This has a major impact on cost of deployment
since the number of daily transactions in the dotCOM zone is approaching 10
billion and so the zone file has to be maintained in RAM at each node in the
ATLAS constellation.
Deploying the current DNSSEC spec without modification would involve a very
significant unnecessary cost. It would also significantly limit the ability
of the registrar to introduce other enhancements that might be required.
A proposal was made to correct the specification that was by all accounts
supported by a clear majority of the group. However this was opposed by one
of the chairs.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg