It would also help quite a bit if we had better encapsulation
technology. Binary plug-ins for browsers are generally a bad
idea -- having things like video players in separate processes
where operating system facilities can be used to cage them more
effectively would also help to mitigate
On Jul 26, 2009, at 11:20 PM, Perry E. Metzger wrote:
Jerry Leichter leich...@lrw.com writes:
While I agree with the sentiment and the theory, I'm not sure that it
really works that way. How many actual implementations of typical
protocols are there?
I'm aware of at least four TCP/IP
Perry E. Metzger pe...@piermont.com writes:
This highlights an unfortunate instance of monoculture -- nearly everyone on
the internet uses Flash for nearly all the video they watch, so just about
everyone in the world is using a binary module from a single vendor day in,
day out.
There are quite
Perry E. Metzger pe...@piermont.com writes:
Jerry Leichter leich...@lrw.com writes:
One way or another, a single implementation usually wins out in the
OSS community.
See above -- even counting only open source, we have *many* implementations.
Heck, there are even multiple independent open
While I agree with the sentiment and the theory, I'm not sure that it
really works that way. How many actual implementations of typical
protocols are there?
For Adobe Flash, there are three separate implementations -- Adobe's
proprietary one, GNU Gnash, and Swfdec.
Gnash is focused on
catalog -- would be screwed. (Instead, of course, just about
everyone out there with a web browser is screwed.)
This highlights an unfortunate instance of monoculture -- nearly
everyone on the internet uses Flash for nearly all the video they watch,
so just about everyone in the world is using a binary
On Jul 26, 2009, at 2:27 PM, Perry E. Metzger wrote:
...[T]here is an exploitable hole in
Adobe's Flash right now, and there is no fix available yet
This highlights an unfortunate instance of monoculture -- nearly
everyone on the internet uses Flash for nearly all the video they
watch,
so
Jerry Leichter leich...@lrw.com writes:
While I agree with the sentiment and the theory, I'm not sure that it
really works that way. How many actual implementations of typical
protocols are there?
I'm aware of at least four TCP/IP implementations in common use, several
common HTTP servers
Thor Lancelot Simon wrote:
On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
these operations. For example, there is no simple way to do the most
common
On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
these operations. For example, there is no simple way to do the most
common certificate validation operation:
John Gilmore [EMAIL PROTECTED] writes:
The Guild, such as it is, is a meritocracy; many previously unknown people
have joined it since I started watching it in about 1990.
The way to tell who's in the Guild is that they can break your protocols or
algorithms, but you can't break theirs.
PS: Of
Thor Lancelot Simon wrote:
As far as what OpenSSL does, if you simply abandon outright any hope of
acting as a certificate authority, etc. you can punt a huge amount of
complexity; if you punt SSL, you'll lose quite a bit more. As far as the
programming interface goes, I'd read Eric's book
[EMAIL PROTECTED] wrote:
On Thu, 2 Oct 2003, Thor Lancelot Simon wrote:
1) Creates a socket-like connection object
2) Allows configuration of the expected identity of the party at the other
end, and, optionally, parameters like acceptable cipher suite
3) Connects, returning error if the
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
Thor Lancelot Simon wrote:
As far as what OpenSSL does, if you simply abandon outright any hope of
acting as a certificate authority, etc. you can punt a huge amount of
complexity; if you punt SSL, you'll lose quite a bit more. As
On Thu, 2 Oct 2003, Thor Lancelot Simon wrote:
1) Creates a socket-like connection object
2) Allows configuration of the expected identity of the party at the other
end, and, optionally, parameters like acceptable cipher suite
3) Connects, returning error if the identity doesn't match.
... it does look very much from the outside that there is an
informal Cryptographers Guild in place...
The Guild, such as it is, is a meritocracy; many previously unknown
people have joined it since I started watching it in about 1990.
The way to tell who's in the Guild is that they can break
On Thu, Oct 02, 2003 at 03:34:35PM -0700, John Gilmore wrote:
... it does look very much from the outside that there is an
informal Cryptographers Guild in place...
The Guild, such as it is, is a meritocracy; many previously unknown
people have joined it since I started watching it in
slightly ranting, you might want to hit del now :)
Ian Grigg wrote:
What is written in these posts (not just the present one)
does derive from that viewpoint and although one can
quibble about the details, it does look very much from
the outside that there is an informal Cryptographers
Guild
perry wrote:
We could use more implementations of ssl and
of ssh, no question.
...more cleanly implemented and simpler to use
versions of existing algorithms and protocols...
would be of tremendous utility.
jill ramonsky replied:
I am very much hoping that you can answer both (a)
and (b)
Guus Sliepen [EMAIL PROTECTED] wrote:
Thor Lancelot Simon wrote:
In that case, I don't see why you don't bend your efforts towards
producing an open-source implementation of TLS that doesn't suck.
We don't want to program another TLS library, we want to create
a VPN daemon.
And RMS didn't
, since Alice can tell all of her friends don't
use Microsoft).
Jill
-Original Message-
From: Don Davis [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 1:26 PM
To: Jill Ramonsky
Cc: [EMAIL PROTECTED]
Subject: RE: Monoculture
Is it possible for Bob to instruct his browser
On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote:
Thanks everyone for the SSL encouragement. I'm going to have a quick
re-read of Eric's book over the weekend and then start thinking about
what sort of easy to use implementation I could do. I was thinking of
doing a C++
Perry E. Metzger [EMAIL PROTECTED] writes:
Guus Sliepen [EMAIL PROTECTED] writes:
In that case, I don't see why you don't bend your efforts towards
producing an open-source implementation of TLS that doesn't suck.
We don't want to program another TLS library, we want to create a VPN
Simon Josefsson [EMAIL PROTECTED] writes:
Several people have now suggested using TLS, but nobody seem to also
refute the arguments made earlier against building VPNs over TCP, in
http://sites.inka.de/~bigred/devel/tcp-tcp.html.
Well, I agree, the most reasonable thing to do is to use ipsec,
At 8:32 PM -0700 10/1/03, Matt Blaze wrote:
It might be debatable whether only licensed electricians should
design and install electrical systems. But hardly anyone would argue
that electrical system designers and installers needn't be competent
at what they do. (Perhaps most of those who would
EKR writes:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature ...
there's another rationale my clients often give for
wanting a new security system, instead of the off-
the-shelf standbys: IPSec, SSL, Kerberos, and the
Don Davis [EMAIL PROTECTED] writes:
EKR writes:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature ...
there's another rationale my clients often give for
wanting a new security system, instead of the off-
,
in which case I will /definitely/ get on with recoding SSL.
Jill
-Original Message-
From: Perry E. Metzger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 3:36 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Monoculture
We could use more implementations
Who on this list just wrote a report on the dangers of Monoculture?
An implementation monoculture is more dangerous than a protocol
monoculture..
Most exploitable security problems arise from implementation errors,
rather than from inherent flaws in the protocol being implemented.
And broad
On 10/01/2003 11:22 AM, Don Davis wrote:
there's another rationale my clients often give for
wanting a new security system, instead of the off-
the-shelf standbys: IPSec, SSL, Kerberos, and the
XML security specs are seen as too heavyweight for
some applications. the developer doesn't want
Matt Blaze wrote:
I imagine the Plumbers Electricians Union must have used similar
arguments to enclose the business to themselves, and keep out unlicensed
newcomers. No longer acceptable indeed. Too much competition boys?
Rich,
Oh come on. Are you willfully misinterpreting what I
Jill Ramonsky wrote:
Is it possible for Bob to instruct his browser to (a) refuse to trust
anything signed by Eve, and (b) to trust Alice's certificate (which
she handed to him personally)? (And if so, how?)
I am very much hoping that you can answer both (a) and (b) with a yes,
ok then yes :)
On Wed, Oct 01, 2003 at 04:48:33PM +0100, Jill Ramonsky wrote:
But I would like to ask you to clarify something about SSL which has
been bugging me. Allow me to present a scenario. Suppose:
(1) Alice runs a web server.
(2) Bob has a web client.
(3) Alice and Bob know each other personally,
Don Davis wrote:
EKR writes:
I'm trying to figure out why you want to invent a new authentication
protocol rather than just going back to the literature ...
note that customers aren't usually dissatisfied with
the crypto protocols per se; they just want the
protocol's implementation to
eric wrote:
The way I see it, there are basically four options:
(1) Use OpenSSL (or whatever) as-is.
(2) Strip down your toolkit but keep using SSL.
(3) Write your own toolkit that implements a
stripped down subset of SSL (e.g. self-signed
certs or anonymous DH).
(4) Design your own
On Wed, Oct 01, 2003 at 04:48:33PM +0100, Jill Ramonsky wrote:
I could do an implementation of SSL. Speaking as a programmer with an
interest in crypto, I'm fairly sure I could produce a cleanly
implemented and simple-to-use version.
Yep. It's a bit of work, and more work to ensure that
Ian Grigg [EMAIL PROTECTED] writes:
This is where maybe the guild and the outside world part
ways.
The guild would like the application builder to learn the
field. They would like him to read up on all the literature,
the analysies. To emulate the successes and avoid the
pitfalls of
Perry E. Metzger wrote:
...
Dumb cryptography kills people.
What's your threat model? Or, that's your threat
model?
Applying the above threat model as written up in
The Codebreakers to, for example, SSL and its
original credit card nreeds would seem to be a
mismatch.
On the face of it,
On Wed, Oct 01, 2003 at 02:34:23PM -0400, Ian Grigg wrote:
Don Davis wrote:
note that customers aren't usually dissatisfied with
the crypto protocols per se; they just want the
protocol's implementation to meet their needs exactly,
without extra baggage of flexibility, configuration
Ian Grigg [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
...
Dumb cryptography kills people.
What's your threat model? Or, that's your threat
model?
Applying the above threat model as written up in
The Codebreakers to, for example, SSL and its
original credit card nreeds would
On Wed, Oct 01, 2003 at 02:24:00PM -0400, Ian Grigg wrote:
Matt Blaze wrote:
I imagine the Plumbers Electricians Union must have used similar
arguments to enclose the business to themselves, and keep out unlicensed
newcomers. No longer acceptable indeed. Too much competition boys?
Guus Sliepen [EMAIL PROTECTED] writes:
You clearly formulated what we are doing! We want to keep our crypto as
simple and to the point as necessary for tinc. We also want to
understand it ourselves.
There is nothing wrong with either goal.
Implementing our own authentication protocol helps
On Wed, 1 Oct 2003, John S. Denker wrote:
According to 'ps', an all-up ssh system is less
than 3 megabytes (sshd, ssh-agent, and the ssh
client). At current memory prices, your clients
would save less than $1.50 per system even if
their custom software could reduce this bulk
to zero.
That's
On Wed, Oct 01, 2003 at 10:20:53PM +0200, Guus Sliepen wrote:
You clearly formulated what we are doing! We want to keep our crypto as
simple and to the point as necessary for tinc. We also want to
understand it ourselves. Implementing our own authentication protocol
helps us do all that.
Ronald L. Rivest [EMAIL PROTECTED] writes:
What is aperture minimization? That's a new term for me...
Never heard of it before. Google has never seen it either...
(Perhaps others on the list would be curious as well...)
I'm sure you have heard of it, just under other names.
The term
Adam Back [EMAIL PROTECTED] writes:
On Wed, Oct 01, 2003 at 08:53:39AM -0700, Eric Rescorla wrote:
there's another rationale my clients often give for
wanting a new security system [existing protcools] too heavyweight for
some applications.
I hear this a lot, but I think that Perry
Don Davis [EMAIL PROTECTED] writes:
eric wrote:
The way I see it, there are basically four options:
(1) Use OpenSSL (or whatever) as-is.
(2) Strip down your toolkit but keep using SSL.
(3) Write your own toolkit that implements a
stripped down subset of SSL (e.g. self-signed
John S. Denker [EMAIL PROTECTED] writes:
According to 'ps', an all-up ssh system is less than 3 megabytes (sshd, ssh-
agent, and the ssh client). At current memory prices, your clients would
save less than $1.50 per system even if their custom software could reduce
this bulk to zero.
Let me
In message [EMAIL PROTECTED], Perry E. Metzger writes:
Unfortunately, those parts are rather dangerous to omit.
0) If you omit the message authenticator, you will now be subject to a
range of fine and well documented cut and paste attacks. With some
ciphers, especially stream ciphers,
unlicensed
newcomers. No longer acceptable indeed. Too much competition boys?
Who on this list just wrote a report on the dangers of Monoculture?
Rich Schroeppel [EMAIL PROTECTED]
(Who still likes new things.)
-
The Cryptography
visible and sexy).
Rich, I know you're a smart guy with great familiarity (and
contributions to) the field, and I know you're not a kook, but
your comment sure would have set off my kook alarm if I didn't
know you personally.
Who on this list just wrote a report on the dangers of Monoculture
on this list just wrote a report on the dangers of Monoculture?
I did. Dependence on a single system is indeed a problem. However, one
must understand the nature of the problem, not diversify blindly.
Some companies are said to require that multiple high level executives
cannot ride on the same plane
newcomers. No longer acceptable indeed. Too much competition boys?
...
Who on this list just wrote a report on the dangers of Monoculture?
I did. Dependence on a single system is indeed a problem. However, one
must understand the nature of the problem, not diversify blindly.
Some
I imagine the Plumbers Electricians Union must have used similar
arguments to enclose the business to themselves, and keep out unlicensed
newcomers. No longer acceptable indeed. Too much competition boys?
The world might be better off if you couldn't call something
secure unless it came
54 matches
Mail list logo
