[cryptography] Why anon-DH is less damaging than current browser PKI (a rant in five paragraphs)

Thierry Moreau thierry.moreau at connotech.com
Tue Jan 8 11:24:39 EST 2013

ianG wrote:
> On 8/01/13 15:16 PM, Adam Back wrote:
> [...] a story about how their bank is just totally 
> hopeless.
> [...]
> So.  Totally hopeless.  A recipe for disaster.
> Obviously we cannot fix this.  But what we can do is decide who is 
> responsible, and decide how to make them carry that responsibility.
> Hence the question.  Who is responsible for phishing?
> Vendor?  CA?  User?  Bank?  SSL techies?

If it's about liability allocation, I'll leave others to comment.

If it's about what might be envisioned by each actor group, I have an 
observation about SSL techies. I guess I qualify as among the group, but 
my difficulty is to train other techies about the consequences of crypto 
scientific/academic results.

Two cases where SSL techies seem hopeless (to me) in applying academic 

The MD5 brokenness got serious attention from the PKI community only 
when an actual collision was shown on a real certificate, no sooner 
(this particular work has little value as a scientific contribution 
besides its industrial impact). Even worse, the random certificate 
serial number short term patch has become "best practice" and PKI 
techies now come up with fantasies about its rationales (see discussion 
starting at 
http://www.ietf.org/mail-archive/web/pkix/current/msg32098.html ).

Dan Bernstein made (with help of colleagues) a demonstration that DNSSEC 
NSEC3 mechanism comes with an off-line dictionary attack vulnerability 
as a "DNS zone walking" countermeasure. DNSSEC techies just flamed the 
messenger (on other grounds), ignored the warning, and quietly left the 
vulnerability in oblivion. Professor Bernstein moved to other issues.

For the record, DNS zone walking is a DNS privacy threat introduced by 
plain DNSSEC (e.g. the attacker quickly discovers 
s12e920be.atm-network.example.com because atm-nework.example.com is 
DNSSEC-signed without NSEC3). The NSEC3 patch development delayed DNSSEC 
protocol completion by a few years. The prof Bernstein presentation came 
after the DNSSEC RFC's were done.

So, when trying to promote an IT security innovation (e.g. if phishing 
could be reduced by some scheme that would protect the banks against 
their own incompetence), the typical expert in the audience is subject 
to this kind of short sightedness about established practice.

So, I would envision any strategy to make academic results and IT 
security innovation more palatable to IT experts. This is how I feel 
responsible for the hopeless phishing minefield!


- Thierry Moreau

More information about the cryptography mailing list