On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well
managed.
In all but a single instance I have no evidence to the contrary.
The one case of an exploit was extremely well publicized and
ameliorated within days. And that was years ago.
Trust Models.
Once a CA is vetted, it can be leveraged as a point of trust. The
trust is of an association with a URL validated by the certificate.
This works for the most part, with notable exceptions. The fact that
exceptions are notable is notable.
When short cuts are taken in PKI as with SMTP, there should be some
concern.
DKIM voids vetted CAs, as the public key is obtained from DNS, this
provides the URL association directly.
Although DKIM depends upon DNS, it makes two significant compromises.
1) The only anti-replay mechanisms available are:
- direct association of SMTP client with signing domain.
- per-user keys.
- SPF to associate SMTP client with signing domain.
2) The only authorization mechanisms available are:
- ad-hoc exchange of public or private keys.
- delegating DNS key zone.
Replay-abuse:
Direct association with an SMTP client is not always practical.
Timely per-user key cancelation is unlikely, and may even cause DNS
to become inundated with short-lived key records.
SPF allows bad actors to "script" a series of transactions through
_any_ remote DNS cache.
Granting this access via SPF to bad actors places potential victims
at substantial risk of being inundated. SPF is macro expanded for
each email-address checked. A spam campaign originating from a
domain of many local-parts will be able to instantiate hundreds of
DNS transactions per message. Why not, the attack will be free to
any spammer. The victims of bad actors can be attacked from the same
cached long lived SPF record. Poisoning DNS usually starts by
preventing an authoritative DNS from responding, where then directing
remote domains to make a series of queries would be needed. SPF
enables both tasks.
Proponents of SPF scripts felt that granting bad actors such access
to remote DNS resolvers was justified. Their justification was based
upon the level of damaged that might be caused by a chain of bogus NS
records anyway. Of course any such susceptibility to bogus NS record
chaining can be handled with changes to the DNS protocol. Damaged
created by SPF can not be handled by such changes to DNS. In
addition, bogus NS record chaining can also be greatly amplified by
SPF. Bogus NS record chaining should have increased the concern,
instead just opposite resulted. : (
Unfortunately, while DNSsec might avoid the cache poisoning enabled
by SPF, it will also increase the odds of SPF of being successful at
staging a DDoS attack.
Lack of authorization by-name:
The ad-hoc exchange of keys is a disaster waiting to happen.
Thousands of private keys per server could be at risk. In addition,
who signed has been obfuscated. There is no reason to obfuscate
DKIM's signing process. Users will not be examining signatures and
are unable to understand how it was verified.
Deflecting accountability away from entities transmitting messages
into a public SMTP servers is the reason for:
- SPF's absurdly expansive IP address lists instead of
authorization of by-name.
- DKIM's lack of an authorization by-name mechanism.
DKIM and SPF are less than hopeful signs. The intent of these
schemes is to deflect accountability away from the SMTP client
publicly transmitting the spam. How does this instill trust?
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf