Re: PKI is weakly secure (was Re: Updating the rules?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]