On 2/11/11 6:04 PM, Eddy Nigg wrote:
Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.COM,
BANK0FAMERICA.COM....all goes.
Of course not, that's why we have this:
http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf
Have you actually read that report? It details a rapid response by many
registries to suppress phishing outbreaks like Avalanche, ultimately
leading to its demise and a radically improved takedown rate of phishing
attacks. To the extent that it didn't work, it was due to phishers
targeting less responsive registries (although it discusses improvements
in this area). On the contrary, attackers seeking to get DV certs from
CAs can get a new cert for the *same domain* from any less diligent DV
CA. Huzza.
Not that many phishing attacks rely on HTTPS. That report also details
phishing attacks *on people seeking to purchase SSL certificates* in
which the phishing happens over plaintext. If there's any community
that would require an HTTPS connection in order to be successfully
phished, it would be that one.
cryptographic weaknesses
Better done in the client.
Not done or insufficient implemented mostly due to backward
compatibility and other considerations.
Fortunately, no backwards compatibility problems with DANE.
Look, I tire of this exercise. This comes down to your claim that
inserting non-accountable third parties to do some inconsistent policing
of bad behavior and inconsistent checking of key standards (when any
enforcement simply directs attackers to another CA) is more valuable
than the demonstrable systemic benefits of using signed DNS directly. If
anybody else on this list would like to present a more compelling
argument than you have, I'm happy to discuss it... but I don't think
that the two of us will make any progress with more back-and-forth.
Steve
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto