Tinc's response to "Linux's answer to MS-PPTP"

[Guus Sliepen]

Hello Peter Gutmann and others,

Because of its appearance on this mailing list and the Slashdot posting
about "Linux's answer to MS-PPTP", and in the tinc users' interest, we
have created a section about the current security issues in tinc, which
currently contains a response to Peter Gutmann's writeup:

http://tinc.nl.linux.org/security

I want to emphasize for the cryptography community here that certain
tradeoffs have been made between security and efficiency in tinc. So
please read the response as "why we think we need to do/used to do it
this way" instead of "why we think tinc is still as secure as anything
else". Comments are welcome. 

-- 
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Can Eve repeat?

[Peter Fairbrother]

Ivan Krstic wrote:

> On 24 Sep 2003 08:34:57 -0400, Greg Troxel <[EMAIL PROTECTED]> wrote:
> [snip]
>> In Quantum Cryptography, Eve is allowed to not only observe, but also
>> transmit (in the quantum world observing modifies state, so the notion
>> of read only doesn't make sense).  Also, Eve is typically accorded
>> unlimited computational power.
> [snip]
> 
> The idea that observing modifies state is something to be approached with
> caution. Read-only does make sense in quantum world; implementations of
> early theoretical work by Elitzur and Vaidman achieved roughly 50% success
> on interaction-free measurements. Later work, relying on the quantum Zeno
> effect, raised the success rate significantly: "Preliminary results from
> new experiments at Los Alamos National Laboratory have demonstrated that
> up to 70 percent of measurements could be interaction-free. We soon hope
> to increase that figure to 85 percent."
> 
> The quote comes from a article by Kwiat, Weinfurter and Zeilinger
> published in SciAm, November 1996 -- if they were getting success rates
> like these back then, I wonder what the current status is.
> 
> The article is well worth a read. There's a copy online at:
> http://www.fortunecity.com/emachines/e11/86/seedark.html
> 
> Best regards,
> Ivan Krstic

Thanks for the interesting link.

That's pretty much what I was talking about when I said that it may be
possible to clone an arbitrarily large proportion of photons - and that
Quantum Cryptography may not actually be secure.

For instance, you can clone a "virtual" photon and do an interaction-free
measurement comparing the now-cloned photon and the photon in it's uncloned
state. If they don't match, the photon was incorrectly cloned. You may only
be able to correctly clone 5/6 of the photons, but that way you know which
photons were correctly cloned.

It may also be possible to clone an arbitrarily large proportion of photons,
ie approaching all of them, by measuring the incorrectly cloned photons and
their clones or transforming to get the original photon back, then trying to
clone again. Other methods are perhaps possible too.


The "no-cloning rule" says that no unitary transform will take two quantum
waveforms, one unknown, and generate two wavefoms with the same state as the
unknown waveform. It's probably true (anent some non-linear transform), but
it _doesn't_ say that there isn't another way to clone quanta, perhaps using
three waveforms, or "virtual" waveforms, or generating a new quantum from
interaction-free measurement of the original quantum waveform.

IMO far too much reliance has been placed on it, or perhaps people just
misunderstood what it says.


It reminds me a bit of the "cd's are better than vinyl" dispute - the cd
guys said that Nyquist theorem showed that cd's reproduced music to above
human hearing, but it doesn't, it just shows that less-than-Nyquist sampling
rates have extra problems. And it only applies to steady states, not music.
And so on.

And the "no-cloning rule" _doesn't_ say it's impossible to clone. Perhaps it
should be called somthing else.


-- 
Peter Fairbrother

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Reliance on Microsoft called risk to U.S. security

[martin f krafft]

also sprach Ian Grigg <[EMAIL PROTECTED]> [2003.09.25.2253 +0200]:
> > "I wouldn't put all of the blame on Microsoft," Schneier said,
> > "the problem is the monoculture."
> 
> On the face of it, this is being too kind and not striking at the
> core of Microsoft's insecure OS.  For example, viruses are almost
> totally a Microsoft game, simply because most other systems aren't
> that vulnerable.

Yes and no. First, I think that viruses will surface were e.g. Linux
to take top position, albeit they may have to employ totally new
paradigms to subvert the more advanced security architecture of
UNIX.

But I believe Schneier is right for the following reason: Microsoft
is a monopolist who, despite enjoying bad press for the past four
years, is managing to keep its sales going up each quarter. If you
are in business, what do you care for? The steep sales curve, or the
quality of your product?

As long as Microsoft has the monopoly on the desktop, as long as new
computers come with Windows per default, and as long as people stop
complaining and actually take action against the crap that Redmond
ships by switching to other systems in bulk, Microsoft has no reason
to invest any money in a code rework.

> So, in the market for server platform OSs, is there any view as to
> which are more secure, and whether that insecurity can be traced
> to the OS?

The defacement archive[1] has some statistics. But don't let
yourself be fooled as one should not forget that while Windows
usually comes with one web-, one mail-, one DNS server, there are
like 27 and up in each category for UNIX. So theoretically, when
comparing those categories, you need to include a factor of 27.

  1. http://defaced.alldas.org/

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
 
"women love us for our defects.
 if we have enough of them,
 they will forgive us everything,
 even our gigantic intellects."
-- oscar wilde


pgp0.pgp
Description: PGP signature

Re: Can Eve repeat?

[Greg Troxel]

  That's pretty much what I was talking about when I said that it may be
  possible to clone an arbitrarily large proportion of photons - and that
  Quantum Cryptography may not actually be secure.

A key point is the probability that the measurement/cloning operation
has of disturbing the original state.  Errors at the receiver are
assumed to be the result of eavesdropping.  The current canoncial
paper on how to calculate the number of bits that must be hashed away
due to detected eavesdropping and the inferred amount of undetected
eavesdropping is "Defense frontier analysis of quantum cryptographic
systems" by Slutsky et al:

  http://topaz.ucsd.edu/papers/defense.pdf

(I don't want to take a position on whether cloning is or isn't
possible - that's way out of my area of expertise!)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

A different Business Model for PKI (was two other subjects related to the demise of Baltimore)

[Ed Reed]

I've suspected that the pricing was set along a line of thinking that
goes like this...

1) work group and departmental networking managed to charge $100-$150 /
yr / user
in exchange for making user administration, file and print share access
control
management and other related identity management functions (email)
"easy"
for Windows users.  That price model was successfully set back in the
NetWare 3 and 4
days, and has continued pretty much to the current day.  It made sense
because
managing user accounts and user desktops is really, really expensive in
terms of
personnel costs.

2) PKI vendors looked at that and must have said - gee, if we can get
$100-$150/yr/user
for managing identity around PKI certificates, why shouldn't we?  And
so they tried.
Some of their offerings, securing VPNs, b2b file transfers, etc. were
good, but
things like S/MIME (really just updated PEM) still aren't worth it,
given how difficult
it STILL is, even with ubiquitous directories, to manage individual
cert lifecycles for users
when personnel turnover approaches 30% per year.

3) the standards groups, PKIX in particular, still haven't addressed
the cert life cycle
management issues, and neither has the market place, in any coherent,
interoperable
fashion - they've got their hands full getting simple things like LDAP
storage of certs
working right, and are more interested in computing trust across
arbitrarily long
chains of root ca cross certifications (bridges).

4) the PKI vendors IPO's were based on the $100-$150/yr/user business
model

5) because of #3, customers wouldn't pay, resulting in the "shakeout"
in the industry

6) new markets for PKI, like companies who want to issue identity
certs
to each of their customers, or manufacturers of, say, cable settop
boxes or mobile phones,
who need end-point-authenticated out-of-the-box self-registration and
accountably
secureable connections for MILLIONS of new devices / customers per year
can't
get the PKI vendors to budge on their rediculous price points, so they
look elsewhere.

After some research, it appears to me that there's a tidy little
business possible for
someone to break the mold.

Sell PKI software the same way you sell Manufacturing software - on the
basis
of the size and complexity of your installation and its support costs,
not on the 
basis of the number of widgets you manufacture.

Price points between $0.002 and $0.20 per cert would allow someone
needing
20 million certs to buy for $40K - $4M, depending on how integration
complexity
they have.  Add-on sales for insurance and warrantee (for loss of
business
coverage) and high assurance operational costs they need to cover
their
own liability would be extra.  Certs need not expire very quickly -
these are identity certs
that can last as long as the device / policy holder lasts, or until
technology
makes them obsolete.  I wouldn't even price it per cert, but you've got
to
have the comparison available to show the difference.  The point is
that
$1M-$4M is well within reason for many of these kinds of applications,
but
$100 x 20M = $2,000M isn't.  To be fair, vendors in discussion for
these
kinds of applications appeared to be willing to "come down" to $40M or
so, or about $2 per cert per year - still an order of magnitude too
much.

The business profits come from charging for consultant aided
integration of 
the key generation (where key escrow is desired) and certificate
signing requests into order processing and manufacturing operations, so
that
chips or customer databases are populated with identity information
when
the device is manufactured.  Registration occurs when the device comes
alive and contacts its pre-configured service depot at power up to
receive
configuration / customer policy information customized for its use.  Or
when
the policy holder connects to the customer portal and authenticates
via password / pass phrase / policy information knowledge (the same
way registration for phone access to policy information is provided
today).

Using PKI in these applications is completely different from the S/MIME
model,
but addresses real business needs.  It allows out-of-the-box strong
authentication of devices at power on (assuming network connectivity). 
That
provides for a whole new raft of delivery chain customer service and
provisioning
solutions that are really cumbersome, today, without PKI.  For
customer
databases, it allows the vendor to use PKI-based authentication from
portal
servers into back-end systems (you really, really don't want to think
about
provisioning 20,000,000 consumer's browsers with personal certs, do
you?  Why,
do you own a customer support phone bank needing work?) while
supporting
smart card and other stronger authentication into the same back end
systems
for administrators and customer support folks, with full accountability
(auditability)
and separation of duties based on the strengths of the authentication /
cert
key protection (documented by the CAs who issue the certs based o

Re: Reliance on Microsoft called risk to U.S. security

[Victor . Duchovni]

On Thu, 25 Sep 2003, Ian Grigg wrote:

> On the face of it, this is being too kind and not
> striking at the core of Microsoft's insecure OS.  For
> example, viruses are almost totally a Microsoft game,
> simply because most other systems aren't that vulnerable.
>

While part of the security problems in Windows are Microsoft specific, in
my view a large part is inherited from earlier graphiscal desktop designs,
and is almost universal in this space. Specifically, when a user clicks
(or double-clicks) on an icon there is not a clear distinction between
"Run" and "View". Instead we have the polymorphic "Open".

If files always opened in a safe viewer, (e.g. clicking on a .pl file
fired up an editor, not the ActiveState Perl interpreter) a good part of
the security problem with Graphical desktops, Microsoft's, Apple's,
RedHat's, ... would be solved. The bizarre advice we give users to not
open message attachments would be largely unnecessary (one also needs to
close the the macro invocation problem, but this is not insurmountable).

It is my contention that so long as activating an icon does not
distinguish between "Run" and "View" all Graphical Shells will be
insecure.

-- 
Victor Duchovni
IT Security,
Morgan Stanley

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

The Right Touch

[R. A. Hettinga]

Forbes




OutFront 
The Right Touch 
Elizabeth Corcoran, 10.13.03 


We're spending billions for new voting machines that may not be any better than punch 
cards 
Three weeks before California was set to vote on Governor Gray Davis' recall, a 
federal appeals court postponed the election because of worries about flawed 
punch-card voting systems. The technology that could replace it may not be any better. 

Touch-screen voting systems, which look like automated teller machines, are easy to 
use, but they make recounts next to impossible--because, unlike ATMs, they produce no 
independent paper trail. That worries experts who insist they can be hacked, just like 
any computer. "It's very, very hard to make these machines secure," says David Dill, a 
computer science professor at Stanford who has studied computer voting. 

The companies that make the new voting systems are steaming at these accusations. 
"They're suggesting something magically happens between what you see on the screen and 
what's stored in the machine,"says Thomas Swidarski, president of Diebold Election 
Systems. 

Voting technology became big business following Florida's swinging-chad fiasco in 
2000. Last year Congress voted to dish out $3.8 billion to the states to upgrade 
voting booths and train poll workers. The dollars are going to a handful of firms, 
including Diebold, Sequoia Voting Systems and Election Systems & Software. Diebold, 
the $2 billion (revenues) maker of safes and automated teller machines, has placed 
47,000 voting machines, which cost as much as $3,500 apiece, in Georgia, Maryland, 
California, Virginia, Texas and Indiana. Ohio is reviewing a half-dozen bids to equip 
11,614 precincts. One-third of California voters are supposed to be using touch 
screens to vote in March (most of the rest will be optically scanned). A state 
commission is still reviewing whether to recommend adding receipts to the machines. 

Touch-screen voting machines don't have keyboards, Internet connections or even ports 
that hackers could exploit. Votes are stored in duplicate, in a removable card locked 
inside the voting machine and in built-in semiconductor memory. The only way in is 
through the smart cards handed out at the polls. The system is supposed to be 
idiot-proof--voters cannot pick too many candidates. 

But what about security? In late July Johns Hopkins computer scientist Avi D. Rubin 
released a paper criticizing computer code discovered on the Internet that was an 
excerpt of the programming in Diebold's touch-screen machines. Rubin argued the 
cryptographic protection was so poor that a hacker could easily make illegal smart 
cards and register multiple votes. The paper prompted Maryland to delay awarding a $56 
million contract for 11,000 machines to Diebold. 

Diebold countered that the code was out of date and out of context. Election workers, 
for instance, help combat fraud by taking precautions such as matching the number of 
card users to the votes registered. Diebold also issued a press release outing Rubin 
as an adviser to an Internet election technology company, VoteHere. He has since quit. 

But Diebold earned itself a black eye when its chairman, Walden O'Dell, sent a 
fundraising letter in August to Ohio Republicans, pledging that he is "committed to 
helping Ohio deliver its electoral votes to the president next year." 

Accidents happen. Officials in Florida's Miami-Dade County are weighing the cost and 
benefits of retrofitting 7,200 voting machines with printers after voters there had 
trouble with touch-screen systems built by ES&Sfor the 2002 elections. Some voters 
reported that the machines registered a vote for a different candidate than the one 
they picked. 

Undetectable problems worry computer scientists even more. "Software could shape the 
outcome of a surprise election--and we'll never know," says Dill. 



Sidebars 
Stacking The Deck 
-



-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

efficiency?? vs security with symmetric crypto? (Re: Tinc's response to "Linux's answer to MS-PPTP")

[Adam Back]

What conceivable trade-offs could you have to make to get acceptable
performance out of symmetric crypto encrypted+authenticated tunnel?
All ciphers you should be using are like 50MB/sec on a 1Ghz machine!!

If you look at eg cebolla (more anonymity than VPN, but it's a nested
forward-secret VPN related thing) it's even possible to do pretty
immediate forward secrecy every second or something at minimal CPU
cost.  (I'll read the writeup but that trade-off argument sounds very
wrong.)

Adam

On Fri, Sep 26, 2003 at 12:12:03PM +0200, Guus Sliepen wrote:
> Hello Peter Gutmann and others,
> 
> Because of its appearance on this mailing list and the Slashdot posting
> about "Linux's answer to MS-PPTP", and in the tinc users' interest, we
> have created a section about the current security issues in tinc, which
> currently contains a response to Peter Gutmann's writeup:
> 
> http://tinc.nl.linux.org/security
> 
> I want to emphasize for the cryptography community here that certain
> tradeoffs have been made between security and efficiency in tinc. So
> please read the response as "why we think we need to do/used to do it
> this way" instead of "why we think tinc is still as secure as anything
> else". Comments are welcome. 
> 
> -- 
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <[EMAIL PROTECTED]>

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Reliance on Microsoft called risk to U.S. security

[Bill Frantz]

At 6:47 AM -0700 9/26/03, [EMAIL PROTECTED] wrote:
>While part of the security problems in Windows are Microsoft specific, in
>my view a large part is inherited from earlier graphiscal desktop designs,
>and is almost universal in this space. Specifically, when a user clicks
>(or double-clicks) on an icon there is not a clear distinction between
>"Run" and "View". Instead we have the polymorphic "Open".
>
>If files always opened in a safe viewer, (e.g. clicking on a .pl file
>fired up an editor, not the ActiveState Perl interpreter) a good part of
>the security problem with Graphical desktops, Microsoft's, Apple's,
>RedHat's, ... would be solved. The bizarre advice we give users to not
>open message attachments would be largely unnecessary (one also needs to
>close the the macro invocation problem, but this is not insurmountable).
>
>It is my contention that so long as activating an icon does not
>distinguish between "Run" and "View" all Graphical Shells will be
>insecure.

The real problem is that the viewer software, whether it is an editor, PDF
viewer, or a computer language interpreter, runs with ALL the user's
privileges.  If we ran these programs with a minimum of privilege, most of
the problems would "just go away".

See:
http://www.combex.com/tech/edesk.html
http://www.combex.com/papers/darpa-review/index.html
http://www.combex.com/papers/darpa-report/index.html

Cheers - Bill


-
Bill Frantz| "There's nothing so clear as   | Periwinkle
(408)356-8506  | vague idea you haven't written | 16345 Englewood Ave
www.pwpconsult.com | down yet." -- Dean Tribble | Los Gatos, CA 95032


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Tinc's response to "Linux's answer to MS-PPTP"

[Joseph Ashwood]

And a response. I have taken the liberty of copying the various portions of
the contents of the webpage to this email for response. I apologize for the
formatting confusion which may mistake Peter Gutmann's comments with those
of the semi-anonymous misinformed person under scrutiny.

I would have CC'd the author of the response page, but it fails to mention
an author, in spite of the "Comments are welcome" statement at the
beginning.

> On September the 15th Peter Gutmann contacted us and showed us part of a
writeup which he
> posted to a cryptography mailing list on the 22th. In this writeup he
identifies several security issues
> in CIPE, VTun and tinc. Below we will examine his findings and explain why
some flaws or
> weaknesses Peter Gutmann found are in fact not a problem at all for a VPN
daemon like tinc.
> As a reader you are ultimately left to draw your own conclusions, I
encourage you to read all the
> arguments from both sides and, if possible, verify them by reading the
documentation and source
> code of tinc. Comments are welcome.

> Predictable IV
Proposed solution: provide the option of a "full IV and move the sequence
number out of the ciphertext," note that this is an _option_, instead of the
necessary for security always.

> Truncated MAC
> tinc will continue to use only the first 32 bits by default.
Simply put this is unacceptable from a security standpoint. The view taken
is that the extra 128 bits represents a significant overhead in the
communication. So I did the math, sending the extra 128 bits over a 52kbs
would take 0.002 seconds, and over a T1 the time cost is an absolutely
enormous 0.8 seconds. The other consideration is the potentially the
computation time argument, but SHA-1 is used regardless, the computation
time is identical. There is no justification in even a dialup environment
for not using the full HMAC.

> Use of RSA
> Tinc uses RSA encryption only once, during authentication.
 Yeah authentication is such a minor thing that major flaws are
completely aceptable.

> A message is sent which has the same length as the RSA key, and is
> completely filled . . .using real random data (OpenSSL's RAND_bytes()).

I really wish people would actually read documentation *before* making
stupid claims like this, in fact to quote the OpenSSL docs "These functions
implement a cryptographically secure pseudo-random number generator (PRNG).
" Any claim that OpenSSL implements a "real" random number generator are
completely false.

> So, the message does not have low entropy and doesn't contain predictable
> bits.

Read the docs, the message has 0 entropy (actually marginally above 0, but
these are simple rounding errors), that's what a pseudo-random number
generator means.

> However, there is no guarantee that the message was encrypted using the
> correct public key or that noone has tampered with it. This is of no
concern
> for tinc though.

There goes that authentication doesn't matter problem again, remind is tinc
supposed to have any sembalnce of security? or is it just a stupid toy
designed for young children to keep they're even younger siblings out of
their personal matters?

> Part of the message is used as the key for the symmetric cipher that is
used
> by the sender of this key to encrypt the rest of the messages it will
send. A
> challenge-response exchange right after exchanging the RSA encrypted
> messages is done to ensure that both the sender of the symmetric cipher
key
> has the right public key, the recipient has the right corresponding
private
> key, and the message was not tampered with (because that would change the
> symmetric cipher key).

Whoever designed and stated this has no idea about cryptographic security.
Using a "part" of a shared secret, generated by a pRNG on only one side,
introduces horrific flaws in the protocol. Pretending that poorly done RSA
encryption magically solves the problem will only risk everything that has
ever been encrypted using tinc.

> Authentication protocol
> First of all, we assume Mallet does not know the private keys of Bob and
> Alice (Bob and Alice are not compromised), and Bob and Alice do not know
> Mallet at all (they don't trust Mallet, otherwise he could've made a
> connection without having to resort to a cryptographic attack).
Good luck keeping that assumption true, with the oracle attack listed above
that won't stay true very long at all.

> First, keys for the
> symmetric cipher encryption are exchanged. Mallet cannot decrypt keys he
> gets from Bob and Alice, because he doesn't have their private keys.
But he does, he spoofed each connection and acted as initiator for both, now
it's a simple matter of resending. Your entire model is based on a
misunderstanding of what RSA does and does not offer.

What you're missing is that the connection iniator sets all the keys and can
determine all the keys (assuming the uncontested simplified message flow is
correct). Mallet can very easily perform a complete man-in-the-middl

Re: A different Business Model for PKI (was two other subjects related to the demise of Baltimore)

[Peter Gutmann]

"Ed Reed" <[EMAIL PROTECTED]> writes:

>2) PKI vendors looked at that and must have said - gee, if we can get
>$100-$150/yr/user for managing identity around PKI certificates, why
>shouldn't we?  

Actually it's even better than that, the companies using the managed service
are still expected to act as the RA (registration authority) for certs, so
they do all the hard work (verifying users, etc etc).  Verisign just give them
access to a cert-management engine and collect the fees (OK, there's a bit
more work to it than that, but still, the Verisign beancounters must be like
pigs in clover over it).

>3) the standards groups, PKIX in particular, still haven't addressed the cert
>life cycle management issues, and neither has the market place, in any
>coherent, interoperable fashion 

That's my perpetual gripe with PKIX, they're frantically busy distracting
themselves with interesting (to them) but ultimately pointless and irrelevant
additional standardisation of features so obscure that you need 15 pages of
diagrams just to explain to users why they might be useful, while ignoring the
fact that most people can't use even the most rudimentary parts of what's
already there.  This is presumably why the IETF finally shut them down, they
realised they'd just keep endlessly churning out RFCs until the sun goes out
(I'm not sure whether just leaving them alone to do that in perpetuity
wouldn't have been the better option).

>After some research, it appears to me that there's a tidy little business
>possible for someone to break the mold.

Can't be done.  SPKI tried it, designing an eminently workable PKI (for the
task they were trying to solve) and no-one was interested because it wasn't
X.509.  Certainly if you throw out all the X.500 baggage that we know doesn't
work (X.500 DNs, directories, CRLs, etc etc, which is what SPKI did) you can
build a very workable, usable, scalable PKI, but OSI digital ancestor-worship
requirements say that you're not allowed to do that.

>Anyone care to make a go of it? 

Please, go ahead.  I'll stand over here and watch.

It's a vicious circle, X.509 doesn't work/doesn't do what people want, but
anything that does work isn't X.509 and therefore won't be accepted by the
market.  SPKI was a heroic effort to break out of the cycle, but despite a lot
of work and input from some very clever people, it ultimately failed for that
reason.  And unlike the OSI experience in the 1980s (which X.509 is a direct
repeat of), for PKI there isn't any DARPA-spawned white knight to come in and
fix things when it fails.

To some extent this is computer darwinism in action.  With networking
protocols, some alternative to OSI (that is, a relatively functional set of
networking protocols) had to evolve at some point, because computers had to
communicate somehow.  There was intense market pressure to get something that
worked, and eventually it was the IP protocol suite.  With PKI on the other
hand no such pressure exists, since it's pretty much irrelevant for most
people.  Sure, your marketing folks can come up with all sorts of neat
hypothetical scenarios where PKI would make things so much better, but in
reality people and companies can do their banking, tax filing, buying and
selling, share trading, and every other use that might justify a PKI,
perfectly well without it.  As a result there's no pressure on the people
involved in PKI standardisation to create anything that meets any real-world
requirement, allowing them instead to spend their time building great gothic
cathedrals of infinite complexity whose sole purpose seems to be to strike awe
and terror into the masses.

What's left to vendors is a few niche markets, generally the same groups who
are still trying to make a go of using X.400 (government departments/the
military, a few large corporates, a few banks) who will keep struggling with
X.509 for a number of years.  That's a pretty small market to peddle your
wares into, as companies like Baltimore, Entrust, and a number of other PKI
vendors have found out.

Peter (who probably now officially qualifies as a PKI curmudgeon).

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Dan Geer Fired (was re: Technology Firm With Ties to Microsoft Fires Executive Over Criticism)

[R. A. Hettinga]

Sep 25, 2003

Technology Firm With Ties to Microsoft Fires Executive Over Criticism
By Ted Bridis
The Associated Press

WASHINGTON (AP) - The chief technology officer for a technology firm that
works closely with Microsoft Corp. lost his job after he helped write a
study critical of the insecurity of Microsoft software.

Daniel E. Geer Jr., an expert with nearly three decades studying technology
and computer security, learned Thursday he was no longer employed by
AtStake Inc. of Cambridge, Mass.

AtStake declined to say whether Geer resigned or was fired. Spokeswoman
Lona Therrien said Microsoft did not call for Geer's dismissal, which
AtStake said was effective two days ago. Microsoft also said it was not
involved in the decision.

But critics said Geer's firing was reflective of Microsoft's far-reaching
ability in Washington and across the technology industry to silence experts
who complain about weaknesses in its software or its aggressive business
practices. The Justice Department struggled years ago to find technology
executives willing to testify against Microsoft in its antitrust trial.

Geer could not be reached immediately for comment, but one person familiar
with Geer's situation said he was fired in a call Thursday morning from
AtStake executives.

AtStake has worked closely with Microsoft in the past, examining some of
its software blueprints for security problems and providing consulting
services.

AtStake's announcement came one day after Geer and six other experts
published a report complaining that the U.S. government relies too heavily
on software from Microsoft. It argued that the widespread dominance of
Windows has created an unhealthy "monoculture" inadequately resistant to
viruses and attacks by hackers.

Geer was identified Wednesday in a conference call with journalists as
AtStake's technology officer and the lead author of the report, which was
funded by the Washington-based Computer and Communications Industry
Association, a trade group whose members include some of Microsoft's
biggest corporate rivals.

"The values and opinions of the report are not in line with AtStake's
views," the company said in a statement. It said Geer's participation
working on the report was "not sanctioned."

"Security is much more complicated than focusing on this one issue," said
Chris Wysopal, AtStake's director of research and development. "We think
the way the (CCIA) paper is positioned ... is just not the answer."

Wysopal said experts within AtStake debate about security issues internally
but that Geer represented his views as the company's consensus. "We value
diversity of opinions here," Wysopal said.

Bruce Schneier, the chief technology officer for Counterpane Systems Inc.,
worked with Geer on the report. He said security experts contacted to help
work on the report critical of Microsoft indicated their support but
couldn't participate publicly.

"There is a huge chilling effect based on Microsoft's monopoly position,"
Schneier said. "It's unfortunate that AtStake put its private agenda ahead
of intellectual integrity."

The CCIA trade group also ran into trouble Thursday when it sought to send
a paid announcement about its critical Microsoft report to 140,000
subscribers of popular trade magazines for chief security officers and
chief information officers.

The publisher for CIO and CSO magazines, CXO Media Inc., offers such
announcements "to target a specific market segment of our audience by
designing a list of prospects for direct mail and e-mail purposes."

But in this case, the subject was too touchy.

"We find it is too sensitive of material to send out. I'm sorry to be the
bearer of bad news, but I have to deny your request," according to an
e-mail from the publisher obtained by The Associated Press.

"We need to try to provide some balance on these issues, and this seemed a
little one-sided," CXO spokeswoman Karen Fogerty said.

---

On the Net:

AtStake Inc.: www.atstake.com

Microsoft Corp. www.microsoft.com

CXO Media Inc.: www.cio.com

CCIA: www.ccianet.org

AP-ES-09-25-03 1629EDT

This story can be found at: http://ap.tbo.com/ap/breaking/MGASNQR81LD.html


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]