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

[ianG]

There are two long-term trends that might inform this argument.

1.  Vendors have typically refused to improve the model of browser 
security if it has involved changes to the model.  There is a long 
history of people providing suggestions, papers and code, and the 
vendors have ignored them.  It is one of the more compelling evidences 
that vendors do not have users' interest in mind, taking their guidance 
from the supply side.


1.a the current rebel from the trend is google.  The reason for this can 
be seen in its business makeup.  google unlike the rest is both a vendor 
*and a user*.  As it has come under attack for its second role, it has 
sought to defend.  CAs have not been of any use.  As an 
engineering-heavy company, it has seen engineering improvements that 
could be made.  For this reason, google can be seen to be experimenting 
with changes, and continuing to do so.


We should welcome these early experiments, wherever they come from. 
This is regardless of whether they are good, bad, up or down.  The only 
way to fix the mess is to change internal architectural assumptions of 
the browsing PKI (e.g., including as people have pointed out the 
brittleness of one-for-all and all-for-one aspect, perhaps we should 
refer to at as the 3 Musketeers weakness).  The point here being that 
you might get to consider the really serious problems of the model once 
you have gained some confidence fiddling around at the edges.



2.  The basic flaws of the model and the business structure are forcing 
the vendors to take on a role that might be considered to be a meta-CA, 
sometimes jokingly referred to as the über-CA.  You can see this in the 
quasi-auditing procedure conducted by Mozilla known as their policy, and 
the recent addition of root revocation capabilities in the last 3 years. 
 In the nick of time it might seem, but every action has consequences.




Which is to say, now that vendors have taken on the role, and become the 
über-CAs, they are more likely to PKI-us-harder than lesser.  E.g., 
google's current trend with pinning, CT, and dropping self-signed certs 
are obviously that, as they do more with PKI not less.  It's going to 
take a while before they get frustrated at this.


Point being, it is nice to see someone doing something.  But we aren't 
going to get the direction needed for some time.




On 6/01/13 16:53 PM, Ben Laurie wrote:

On Sun, Jan 6, 2013 at 1:15 PM, Peter Gutmann  wrote:

Ben Laurie  writes:

On Sat, Jan 5, 2013 at 1:26 PM, Peter Gutmann  wrote:

In the light of yet another in an apparently neverending string of CA
failures, how long are browser vendors going to keep perpetuating this PKI
farce? [0].  Not only is there no recorded instance, anytime, anywhere, of a
browser certificate warning actually protecting users from harm [1],


This is patently incorrect: Diginotar were caught by a browser warning.


Well, we think that at least one user was.  We definitely know that 300,000
others weren't.  That's hardly a triumph of browser PKI.

Let's look at the figures in more detail.  There are around a billion users of
the Internet.  Let's say that they go to two SSL-enabled sites a day, probably
a lower bound but it's just a back-of-the-envelope thing.  That's two billion
uses of browser PKI a day, let's call it roughly a trillion a year.  SSL has
been around in significant volume for, say, about 15 years, so that's 15
trillion uses.  The number of people who reported being warned about the
Diginotar cert was, say, a dozen or so, and of that we don't know how many
ignored the warning and clicked through anyway, as they've been conditioned to
do.


My understanding is you can't click through a pinning warning.


There are figures from an earlier invalid-cert case in which exactly one
user out of 300 was turned back by the warning, but let's be generous and say
it was two users who were turned away.  So out of 15 trillion uses of browser
PKI, two worked to protect users.  In other words it has an effectiveness rate
of one in seven trillion.


a) I don't believe your figures, and

b) You are not counting all the people who were protected by the early
detection of Diginotar.


That pretty much makes browser PKI the homeopathy of security.


Certificate Transparency is a real security measure that is a response by a
browser vendor.


So the response to the repeated failure of browser PKI is PKI-me-harder.
Yeah, that's really going to make users safer.


I suspect you don't understand CT - perhaps you'd care to explain why
it is PKI-me-harder?

In any case, its time you updated your out-of-date rant - or, even
better, explained your solution to the problem.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography



___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] another cert failure

[Jeffrey Walton]

On Sat, Jan 5, 2013 at 4:23 PM, Jeffrey Walton  wrote:
> On Sat, Jan 5, 2013 at 3:59 PM, Ryan Hurst  wrote:
>> 
> In the future, we won't need their honesty. Or the 'honesty' they want
> use to perceive.
>
> 
>
> Did anyone really think a CA would risk a multimillion dollar business?
>
Did anything ever emerge about the pre-blog deal?

I suspect Mozilla/Trustwave transpired as follows:

(1) Trustwave issues certificate(s), violates agreements
(2) Trustwave realizes they are exposed to risk that could result in
reputational and financial loss
(3) Trustwave legal engages Mozilla
(4) A deal is brokered
(5) After the deal was executed, Trustwave blogged about the incident.

Everything Trustwave and Mozilla did [publicly] was likely a dog and
pony show to alter our perception of reality.

The outcome was already known and fixed. Otherwise, Trustwave lawyers
would never have agreed to the deal, and the blog never would have
occurred.

Mozilla had to play dumb to ensure it did not suffer reputational
loss; or jeopardize their relationship with Google, which could have
resulted in significant financial loss.

That also explains why the safety net failed.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[James A. Donald]

On 2013-01-07 9:20 AM, Peter Gutmann wrote:

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?

The fundamental cause of phishing is that it is so easy to present a 
false email identity.


A phisher is typically representing himself as an entity with which you 
have a login relationship.


To protect against login phishing, we need to both provide 
password-authenticated key agreement 
, and 
also provide some method whereby entities that have a login relationship 
with you can communicate, and get automatically protected from spam 
filtering and flagged as coming from an entity where you have a login 
relationship - for example, whenever you logged in, your email client 
would get information associating a public key with that login 
relationship.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Peter Gutmann]

Ben Laurie  with:

>a) I don't believe your figures,

Well I don't believe in the tooth fairy, but in this case you're going to have
to provide a more convincing rebuttal than "I choose not to believe in this
inconvenient information".

>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, 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?

>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

  (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.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] another cert failure

[Jeffrey Walton]

On Fri, Jan 4, 2013 at 6:40 PM,   wrote:
>
> you may have already seen this, but
>
> http://www.bbc.co.uk/news/technology-20908546
>
> Cyber thieves pose as Google+ social network
>
> ...
>
> The fake ID credentials have been traced back to Turkish security
> firm TurkTrust which mistakenly issued them.
Interesting Apple appears to have 7 certificates preloaded from
them. http://postimage.org/image/6mdnzus9f/.

They must be very popular in the Mediterranean.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Key Archive Formats and Pinsets (Certificate Pinning)?

[Jeffrey Walton]

H All,

Does anyone know if there is a standard extension to store pin sets
(re: certificate pinning) in, for example, PKCS #12?

Perhaps in another format?

OIDs?

Placing a pinset in a PKCS #12 certificate  (or other format) kills
two key distribution problems with one stone.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How much does it cost to start a root CA ?

[Natanael]

Bitcoin based DNS? That would be Namecoin. I am unsure if it also manages
SSL or similiar link encryption or if that is a separate thing for the
scheme.
Den 6 jan 2013 08:27 skrev "James A. Donald" :

> On 2013-01-05 12:07 PM, Morlock Elloi wrote:
>
>> Correct. The cost of being CA is equal to the cost of getting CA signing
>> pub key into the target audience browsers.
>>
>> You can (sorted by increasing security, starting with zero):
>>
>> 1 - go through browser vendors,
>> 2 - have your users to install additional CA key into their existing
>> browsers (and perhaps remove others), or
>> 3 - distribute your own browser package.
>>
>> Pick one.
>>
>
> Most of the browsers are open source.  A fork could be justified by adding
> privacy value or security value, as, for example, SRWare Iron or the Tor
> browser.
>
> This also applies pressure on the major browsers to refrain from too
> flagrantly violating their customer's privacy.
>
> Perhaps we need a browser that facilitates communication and interaction
> between the holder of one bitcoin key and the holder of another.
> __**_
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/**mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Ben Laurie]

On Sun, Jan 6, 2013 at 1:15 PM, Peter Gutmann  wrote:
> Ben Laurie  writes:
>>On Sat, Jan 5, 2013 at 1:26 PM, Peter Gutmann  
>>wrote:
>>> In the light of yet another in an apparently neverending string of CA
>>> failures, how long are browser vendors going to keep perpetuating this PKI
>>> farce? [0].  Not only is there no recorded instance, anytime, anywhere, of a
>>> browser certificate warning actually protecting users from harm [1],
>>
>>This is patently incorrect: Diginotar were caught by a browser warning.
>
> Well, we think that at least one user was.  We definitely know that 300,000
> others weren't.  That's hardly a triumph of browser PKI.
>
> Let's look at the figures in more detail.  There are around a billion users of
> the Internet.  Let's say that they go to two SSL-enabled sites a day, probably
> a lower bound but it's just a back-of-the-envelope thing.  That's two billion
> uses of browser PKI a day, let's call it roughly a trillion a year.  SSL has
> been around in significant volume for, say, about 15 years, so that's 15
> trillion uses.  The number of people who reported being warned about the
> Diginotar cert was, say, a dozen or so, and of that we don't know how many
> ignored the warning and clicked through anyway, as they've been conditioned to
> do.

My understanding is you can't click through a pinning warning.

> There are figures from an earlier invalid-cert case in which exactly one
> user out of 300 was turned back by the warning, but let's be generous and say
> it was two users who were turned away.  So out of 15 trillion uses of browser
> PKI, two worked to protect users.  In other words it has an effectiveness rate
> of one in seven trillion.

a) I don't believe your figures, and

b) You are not counting all the people who were protected by the early
detection of Diginotar.

> That pretty much makes browser PKI the homeopathy of security.
>
>>Certificate Transparency is a real security measure that is a response by a
>>browser vendor.
>
> So the response to the repeated failure of browser PKI is PKI-me-harder.
> Yeah, that's really going to make users safer.

I suspect you don't understand CT - perhaps you'd care to explain why
it is PKI-me-harder?

In any case, its time you updated your out-of-date rant - or, even
better, explained your solution to the problem.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Ralph Holz]

>> Certificate Transparency is a real security measure that is a response by a
>> browser vendor.
> 
> So the response to the repeated failure of browser PKI is PKI-me-harder.  
> Yeah, that's really going to make users safer.

I don't see why CT is PKI-me-harder. EV or BR would fall into that
category. But why CT? It is a very useful monitoring tool, and has some
advantages over Sovereign Keys.

Ralph

-- 
Ralph Holz
Network Architectures and Services
Technische Universität München
Phone +49 89 28918043
http://www.net.in.tum.de/de/mitarbeiter/holz/
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Peter Gutmann]

Ben Laurie  writes:
>On Sat, Jan 5, 2013 at 1:26 PM, Peter Gutmann  
>wrote:
>> In the light of yet another in an apparently neverending string of CA
>> failures, how long are browser vendors going to keep perpetuating this PKI
>> farce? [0].  Not only is there no recorded instance, anytime, anywhere, of a
>> browser certificate warning actually protecting users from harm [1],
>
>This is patently incorrect: Diginotar were caught by a browser warning.

Well, we think that at least one user was.  We definitely know that 300,000
others weren't.  That's hardly a triumph of browser PKI.

Let's look at the figures in more detail.  There are around a billion users of
the Internet.  Let's say that they go to two SSL-enabled sites a day, probably
a lower bound but it's just a back-of-the-envelope thing.  That's two billion
uses of browser PKI a day, let's call it roughly a trillion a year.  SSL has
been around in significant volume for, say, about 15 years, so that's 15
trillion uses.  The number of people who reported being warned about the
Diginotar cert was, say, a dozen or so, and of that we don't know how many
ignored the warning and clicked through anyway, as they've been conditioned to
do.  There are figures from an earlier invalid-cert case in which exactly one
user out of 300 was turned back by the warning, but let's be generous and say
it was two users who were turned away.  So out of 15 trillion uses of browser
PKI, two worked to protect users.  In other words it has an effectiveness rate
of one in seven trillion.

That pretty much makes browser PKI the homeopathy of security.

>Certificate Transparency is a real security measure that is a response by a
>browser vendor.

So the response to the repeated failure of browser PKI is PKI-me-harder.  
Yeah, that's really going to make users safer.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

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

[Ben Laurie]

On Sat, Jan 5, 2013 at 1:26 PM, Peter Gutmann  wrote:
> In the light of yet another in an apparently neverending string of CA
> failures, how long are browser vendors going to keep perpetuating this PKI
> farce? [0].  Not only is there no recorded instance, anytime, anywhere, of a
> browser certificate warning actually protecting users from harm [1],

This is patently incorrect: Diginotar were caught by a browser warning.

> but the
> blind faith that browsers place in certificates is actively harming users when
> things fail, as they have again and again and again.
>
> Users, or at least technical ones with enough knowledge to understand the
> issues, have completely lost faith in browser PKI.  If you look at discussion
> threads on technical forums [2], browser PKI is seen purely as something to
> roll your eyes at, to make jokes about.  No-one (and as before that's with an
> implied "who understands the details") has any faith in it any more.
>
> The total inability and/or unwillingness of the browser vendors to respond to
> this and provide real security measures that don't involve simply changing the
> silly-walk they do with certificates and continuing as before

Certificate Transparency is a real security measure that is a response
by a browser vendor.

> is not only not
> helping users in any way, it's actively harming them, and users are aware of
> this.
>
> Browsers may as well turn off all their PKI-related code and just use anon-DH
> for everything, which would be safer than the current false-sense-of-security
> silly-walk they're doing, not to mention saving tens (hundreds?) of millions
> of dollars paid to commercial CAs by sites wanting to disable the browser
> warnings.
>
> Browser PKI costs a fortune to run, it doesn't protect users from anything the
> attackers are doing, and at worst it actively endangers them.  If it was a
> commercial good, RAPEX would have it withdrawn [3].
>
> Peter.
>
> [0] I mean "farce" in its theatrical sense here, "unlikely, extravagant, and
> improbable situations [...] highly incomprehensible plot-wise (due to the
> large number of plot twists and random events that often occur) [...] Farce is
> also characterized by [...] the use of deliberate absurdity or nonsense, and
> broadly stylized performances" (from Wikipedia, which has a more detailed
> definition than e.g. the OED).
>
> [1] See "So Long, And No Thanks for the Externalities: The Rational Rejection
> of Security Advice by Users", Cormac Herley.
>
> [2] And I realise the likes of Slashdot aren't the best of them, but it's the
> most accessible and has the most participants, so it's a quick way to gauge
> public opinion.
>
> [3] "RAPEX is the EU rapid alert system that facilitates the rapid exchange of
> information between Member States and the Commission on measures taken to
> prevent or restrict the marketing or use of products posing a serious risk to
> the health and safety of consumers".
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] How much does it cost to start a root CA ?

[ianG]

On 6/01/13 09:48 AM, Ryan Sleevi wrote:


  Perhaps it's this kind of thinking that leads to failed audits :)


It will, it does, and the information is readily available from the
previous post.

https://www.cabforum.org/Baseline_Requirements_V1_1.pdf Sections 14
through 16

Additionally, https://www.cabforum.org/Network_Security_Controls_V1.pdf
describes a series of controls jointly developed by the browsers and CAs.



Ryan, that's not true.  I know it is easy to market the organsation as 
being open and friendly, but some of us weren't born last night.


I think the truth is that it was developed by CABForum participants.  In 
private.  Right?  And then announced it to the world here:


   12 - June -2012  -- Today, the CA/Browser Forum released a
   draft "Network and Certificate System Security Requirements"
   for public review, comment, and discussion.  Comments may be
   submitted through Friday, 22 June 2012

https://cabforum.org/pipermail/public/2012-June/000114.html

Right?  Truth is important, right?  So faith in the product has a 
foundation?


CABForum participants are on record on that date to push a new 
unreleased standard onto the world through Mozilla's public theater with:


  10 days of public comment?

Right?

For the record:   when was that document first worked on in CABForum?



iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography