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

ianG iang at iang.org
Mon Jan 7 06:33:17 EST 2013


On 7/01/13 13:25 PM, Ben Laurie wrote:
> On Sun, Jan 6, 2013 at 11:20 PM, Peter Gutmann
> <pgut001 at cs.auckland.ac.nz> wrote:
>> Ben Laurie <ben at links.org> with:
....
>>> I suspect you don't understand CT - perhaps you'd care to explain why it is
>>> PKI-me-harder?
>>
>> Because it's a band-aid on a mechanism that doesn't really work in the first
>> place.  The solution to the inability of PKI to protect users isn't to
>> rearrange the PKI deckchairs, it's to adopt a layered risk-management strategy
>> that actually helps protect them.  We have no real evidence of PKI addressing
>> anything that attackers are doing,
>
> This is a bizarre statement in the face of Diginotar.

http://wiki.cacert.org/Risk/History shows no real correlation in 
attacks.  There are many many possible attacks, so...


> Maybe they aren't the attackers that interest you, but they are
> certainly attackers.

... when there are too many possible attacks, and they keep happening, 
attention switches to the architecture, not the attacker.

(Is his focus.)


>> so no matter how much you band-aid it it's
>> not going to help protect users from harm.  "Fixing PKI" isn't the problem,
>> PKI itself is the problem.  It doesn't work, and as long as browser vendors
>> keep distracting themselves by fiddling with even more PKI, they'll never get
>> around to addressing the actual problem.
>>
>>> In any case, its time you updated your out-of-date rant -
>>
>> I'll update it as soon as browser PKI starts working (meaning that we have
>> real evidence that it's effectively preventing the sorts of things attackers
>> are doing, phishing and so on).  Deal?
>
> Phishing is not something that PKI is intended to address.


Yes it is.  The whole point of PKI is to put the user in secure contact 
with the business.  Secure browsing PKI puts the user on the website 
they want to be in.

Phishing is the attack that breaches that in secure browsing PKI.

Don't be confused by the fact that PKI has trouble in this area, and 
technically is trying to do something that could be considered impossible.

As a matter of historical and legal fact PKI was intended to stop this. 
  You can see this writ large in early PKI theoretical models before the 
"secure browsing PKI" evolved.  The fuller security model is also in the 
original Netscape demo of the product -- it was there to deal with 
phishing, inter alia.  The marketing people had it dumbed down because 
of ... absence of phishing :)  The legal agreements of all CAs confirm 
this, although they will never admit it.

It is of course a never ending embarrassment of the CAs and vendors that 
their secure browsing PKI failed to protect against phishing, and it is 
easy to show they are at fault.  It is an interesting exercise to show 
WHY it failed to work, and we can do that too.  It is also one of the 
key facts that caused the CA discussions and vendor discussions to be 
secret:  liability.  CABForum emerged out of discussions caused by ... 
phishing, but the unwritten rule is "NEVER MENTION PHISHING!"

The fact is, PKI was intended to address phishing.


> Sorry about
> that. My point is you make claims that may have been true some years
> ago, but are no longer. Your rant should at least be truthful. I
> realise that "not many people have been defended by cert warnings" is
> less punchy than "no-one has, ever". Once more, sorry about that.


His point is accurate statistically.

The fuller question is whether the number of people defended has been 
worth the effort?  Security is Risk!

If one includes phishing in the equation, then it's looking a bit 
wobbly.  Alternatively, if one has managed to rule out those attackers 
that inconveniently breach the model (phishing), then one is left with 
an absence of an obvious attacker, and suddenly ones security model 
conveniently defends against the attackers we know we can defend against.

Which brings us back to the now infamous security threat model of SSL, 
as expounded in the book;  SSL protects what we know how to protect.

 From a user's perspective, that's circular and pointless.  From an 
attacker's pov, they're laughing all the way to the bank.

 From our security pov, it is a really burning question - we ran the SSL 
experiment for 18 years.  10 years ago, the phishers turned up.  2 years 
the attackers started getting aggressive.

What happened?

Cue to subject line...


>>> or, even better, explained your solution to the problem.
>>
>> I've been explaining it for years (and I'm pretty sure you're aware of at
>> least some of it, since we discussed it when I visited Google a year or two
>> back).  Here's a starter:
>>
>>    In the real world, risk is never binary but always comes in shades of grey.
>>    When security systems treat risk as a purely boolean process, they're prone
>>    to failure because the quantisation that's required in order to produce a
>>    boolean result has to over- or under-estimate the actual risk. What's worse,
>>    if an all-or-nothing system like this fails, it fails completely, with no
>>    fallback position available to catch errors. Drawing on four decades of
>>    experience with security design for the built environment (buildings and
>>    houses) known as crime prevention through environmental design (CPTED), PKI
>>    as Part of an Integrated Risk Management Strategy for Web Security,
>>    presented at EuroPKI 2011, looks at how CPTED is applied in practice and,
>>    using browser PKI as the best-known example of large-scale certificate use,
>>    examines certificates as part of a CPTED-style risk-mitigation system that
>>    isn't prone to all-or-nothing failures.
>>
>>    Link: http://www.cs.auckland.ac.nz/~pgut001/pubs/pki_risk.pdf
>
> CT fits right into that framework, though - it is akin to "put ATMs
> where everyone can see them" and the like.


Well, his point was that it PKIs-me-harder, and you tried to distract 
the conversation by the old excuse - "give me solutions not problems."

PKI-me-harder is correct, it forces the PKI to work better (if it 
works), but it doesn't change the model at all.  He's looking for an 
attack on the real flaws, tho, which needs brave changes.

OK, I agree that Peter is impatient and frustrated.  So am I.  Dealing 
with responsible parties that say "phishing isn't our problem" is pretty 
tiring when $100m a year goes down the tubes because of it.


> I do not claim that CT is a complete solution to all the net's
> problems, but I do claim it is a component along exactly the lines you
> are pushing for. Do I think PKI is a great idea? No, but I _do_ think
> we need _some_ way to encrypt traffic s.t. only the intended recipient
> can decrypt it, and I don't see a quicker way to get there from here
> than PKI + CT. Or even anything that is substantially better.


As I say, in the bigger picture, it is fantastic that a vendor has 
broken ranks and started experimenting.  This is the most significant 
thing to happen since 2010.

At the more detailed level - I wouldn't have done CT.  Nor Peter.  But 
neither of us are you.  Go for it.

PKI isn't going away.  Nor are phishers.  Nor are attackers.  We need 
100 of these.


>>    (That's a slightly updated version of the original talk).
>>
>> I have a much longer version, with references to research papers and actual
>> effectiveness in practice from its use by commercial vendors, if anyone wants
>> the full thing.
>
> I don't doubt the effectiveness of the kind of thing you are talking
> about, but what I would find helpful is something actionable - i.e.
> "if you did X, then users would actually better protected, and it
> won't break the 'net". My experience is that it is quite difficult to
> bridge the gap between fluff that obviously works and concrete actions
> that don't have large downsides.


Biggest barrier is getting code into a browser in order to conduct the 
experiment.  Or a server.  Probably, I claim, google has achieved this 
because it is the user, and the incentives are now apparent.  It is also 
the vendor so the capabilities are present.

Outside google, all there is really is talk.



iang



More information about the cryptography mailing list