lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Feb 2005 10:02:48 -0800
From: "David Schwartz" <davids@...master.com>
To: <bkfsec@....lonestar.org>
Cc: <kbo@....tiscali.de>, "Vincent Archer" <var@...y-all.com>,
	<bugtraq@...urityfocus.com>,
	"Scott Gifford" <sgifford@...pectclass.com>
Subject: RE: International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs.



> David Schwartz wrote:
>
> >
> >	Then somebody else would. Market demand creates solutions.
> > I can't see how
> >the legal issues are any different from the ones they face when
> they label
> >software as adware or spyware.

> Wow.  You just conceded that there is significant pressure on major
> vendors to not counter the CA, and then claimed that some ethereal other
> would magically be able to enforce it where Symantec couldn't.

	What?! I did nothing of the sort. My "then" follows his "if". It does not
concede that his "if" is true, in fact I think it's preposterous.

> Market demand sometimes does create solutions, however to claim that it
> does without fail is a bit naive.

	Didn't say that.

> So, if not Symantec, then who else do you propose would?

	Lavasoft, Computer Associates, Bazooka, Webroot, Zone Labs, and pretty much
every other computer security vendor.

> >	No, they never do so because such strategies only work in
> > very unusual
> >circumstances. Nobody can make a person pay more for something than it is
> >worth.

> History disagrees with you.  So do a number of economists.

	First of all, the unusual circumstances have occured in distorted markets.
Second, it took awhile for people to learn that these strategies almost
never work and to figure out precisely under what circumstances they do
work. As for a number of economists, anyone can find economists to defend
his pet view or pet law.

> >	I'm not assuming anything, I'm making an argument why it would be
> >self-destructive for any CA to adopt such a strategy. That
> doesn't mean they
> >won't do it, people certainly do stupid things when they think
> they can get
> >away with it. But the fact is, CAs can't get away with it. So if
> they think
> >they can, they will quickly be proven wrong.

> It would harm them, yes, but they very well can get away with it.

	Right, until it harms the users.

> >>Also, the fact that the CA market is competitive only further muddies
> >>the waters.  Not all CAs are in the same country and their competition
> >>forces them to be price-competitive.  This reduces the priority of being
> >>responsible.  Or, to use your meat analogy, mass-produced meat tends to
> >>be of a lower quality than individually produced meat products,
> >>particularly in unregulated countries.

> >	I could not disagree more. All a CA has to sell is its
> > trust. The trust is
> >its product. CAs sell trust, they are in the trust business. If
> > a CA loses
> >the trust of browser vendors, it has nothing to sell. If a CA loses the
> >trust of users, pressure will be put on browser vendors.

> It's interesting how you cite market dynamics in your arguments, but
> disregard them when they aren't favorable to your point.

	How so?

> If hundreds of thousands of sites use a particular CA as their root,
> then removing the CA trust from the browser will cause an annoyance for
> the browser consumer, resulting in 1 of 2 possible outcomes:
>
> 1) People learn to modify their configs and setup the CA as trusted.
>
> 2) People move to browsers that trust that CA by default.

	Or people set up that CA to a lower level of trust where they know the
certificate has come from a CA they don't fully trust. Or maybe they
download a list of certificates manually from that CA and don't trust
unknown CAs without querying them with a third party. Or maybe, ...

	You can't predict how the market will work.

> The only way that a CA can lose the trust of the browser users is if the
> browser users understand how the CAs work and understand how to put
> pressure on the browser market to achieve that end result.

	Or someone creates a product that does this for them. You might as well
argue that people can't buy well made cars because they're not mechanics.

> Again, we get back to the fact that most end users (browser market
> customers) can barely turn on their PCs, nevermind understand or care
> about CA trust relationships.  You have to put yourself into that
> position and think like they do before you should ever propose a
> pie-in-the-sky market solution to something like this.

	There is a market in keeping users ignorant. So long as things "just work"
users can stay ignorant, and I assure you, if CAs create a situation that
doesn't "just work", someone else will work hard to come up with a solution
to keep things that way.

> There are millions of people out there who don't trust the MPAA or the
> RIAA, for that matter.  Not having the trust of the people hasn't
> stopped them.  Again, you've chosen a very poor example.

	No, the issue (with the MPAA, I'm not sure how the RIAA got into this) is
not that people trust or don't trust them, the issue is that all they have
to sell is their trust. For the vast majority of people, trusting the MPAA
has never caused them a problem. So the alternatives to the MPAA only target
very specialized markets.

> The market does not inherently protect people.  Anyone who believes that
> is reality impaired and doesn't have a very good understanding of
> history nor economics.

	That's not what I'm saying. I'm saying CAs have a huge interest in making
sure their customers don't get harmed by their actions.

	DS




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ