Re: anonymous DH & MITM

At 10:37 PM 10/1/2003, Peter Gutmann wrote: Tim Dierks <[EMAIL PROTECTED]> writes: >It does not, and most SSL/TLS implementations/installations do not support >anonymous DH in order to avoid this attack. Uhh, I think that implementations don't support DH because the de facto standard is RSA, not be

Re: Monoculture

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 cip

Re: anonymous DH & MITM

Tim Dierks <[EMAIL PROTECTED]> writes: >It does not, and most SSL/TLS implementations/installations do not support >anonymous DH in order to avoid this attack. Uhh, I think that implementations don't support DH because the de facto standard is RSA, not because of any concern about MITM (see below

Re: Monoculture

"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. L

Re: anonymous DH & MITM

In message <[EMAIL PROTECTED]>, Ian Grigg writes: >M Taylor wrote: > >MITM is a real and valid threat, and should be >considered. By this motive, ADH is not a recommended >mode in TLS, and is also deprecated. > >Ergo, your threat model must include MITM, and you >will pay the cost. > >(Presumably

Re: VeriSign tapped to secure Internet voting

On Wednesday 01 October 2003 19:53, Ian Grigg wrote: > "Roy M. Silvernail" wrote: > > On Wednesday 01 October 2003 17:33, R. A. Hettinga forwarded: > > > VeriSign tapped to secure Internet voting > > > > > > "The solution we are building will enable absentee voters to exercise > > > their right to

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

On Wed, 1 Oct 2003, Kevin T. Neely wrote: >bear allegedly wrote... >> "Can be relied on to _only_ deliver text" is a valuable and important >> piece of functionality, and a capability that has been cut out of too >> many protocols with no replacement in sight. >Is delivery really the problem,

Re: Monoculture

Don Davis <[EMAIL PROTECTED]> writes: >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 to sh

Re: anonymous DH & MITM

On Thu, Oct 02, 2003 at 12:06:40AM +0100, M Taylor wrote: > > Stupid question I'm sure, but does TLS's anonymous DH protect against > man-in-the-middle attacks? No, it doesn't. > If so, how? I cannot figure out how it would, > and it would seem TLS would be wide open to abuse without MITM protec

Re: VeriSign tapped to secure Internet voting

"Roy M. Silvernail" wrote: > > On Wednesday 01 October 2003 17:33, R. A. Hettinga forwarded: > > > VeriSign tapped to secure Internet voting > > > "The solution we are building will enable absentee voters to exercise > > their right to vote," said George Schu, a vice president at VeriSign. "The

Re: anonymous DH & MITM

M Taylor wrote: > > Stupid question I'm sure, but does TLS's anonymous DH protect against > man-in-the-middle attacks? If so, how? I cannot figure out how it would, Ah, there's the rub. ADH does not protect against MITM, as far as I am aware. > and it would seem TLS would be wide open to abus

Re: anonymous DH & MITM

At 07:06 PM 10/1/2003, M Taylor wrote: Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable

Re: anonymous DH & MITM

M Taylor <[EMAIL PROTECTED]> writes: > Stupid question I'm sure, but does TLS's anonymous DH protect against > man-in-the-middle attacks? If so, how? I cannot figure out how it would, > and it would seem TLS would be wide open to abuse without MITM protection so > I cannot imagine it would be acce

anonymous DH & MITM

Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security

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

bear allegedly wrote... "Can be relied on to _only_ deliver text" is a valuable and important piece of functionality, and a capability that has been cut out of too many protocols with no replacement in sight. Is delivery really the problem, though? You can deliver all the code you want to an e-ma

Re: VeriSign tapped to secure Internet voting

On Wednesday 01 October 2003 17:33, R. A. Hettinga forwarded: > VeriSign tapped to secure Internet voting > "The solution we are building will enable absentee voters to exercise > their right to vote," said George Schu, a vice president at VeriSign. "The > sanctity of the vote can't be compromise

Re: Monoculture

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-s

Re: how simple is SSL? (Re: Monoculture)

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 t

Re: how simple is SSL? (Re: Monoculture)

At 02:21 PM 10/1/2003 -0700, Adam Back wrote: Maybe but X.509 certificates, ASN.1 and X.500 naming, ASN.1 string types ambiguities inherited from PKIX specs are hardly what one could reasonably calls simple. There was no reason SSL couldn't have used for example SSH key formats or something that

Re: how simple is SSL?

Adam Back <[EMAIL PROTECTED]> writes: > > I hear this a lot, but I think that Perry nailed it earlier. SSL, for > > instance, is about as simple as we know how to make a protocol that > > does what it does. The two things that are generally cited as being > > sources of complexity are: > > > > (1

Re: Monoculture

"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

Re: Monoculture

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 > daemon. Well, then you might consider

VeriSign tapped to secure Internet voting

VeriSign tapped to secure Internet voting=20 By Robert Lemos=20 Staff Writer, CNET News.com=20 http://news.com.com/2100-1029-5083772.html=20 VeriSign announced Monday that it will provide key components of a system d= esigned t

Re: Monoculture

On Wed, Oct 01, 2003 at 04:54:35PM -0400, Thor Lancelot Simon wrote: > > Uhm, before getting flamed again: by "our own", I don't mean we think we > > necessarily have to implement something different from all the existing > > protocols. We just want to understand it so well and want to be so > > c

how simple is SSL? (Re: Monoculture)

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 nailed it earlier. SSL, for > insta

Re: Monoculture

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.

Re: Monoculture

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

Re: Monoculture

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 h

Re: Monoculture

On Wed, Oct 01, 2003 at 02:24:00PM -0400, 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 > Guil

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

On Wed, 1 Oct 2003, Peter Gutmann wrote: >This doens't really work. Consider the simple case where you run Outlook with >'nobody' privs rather than the current user privs. You need to be able to >send and receive mail, so a worm that mails itself to others won't be slowed >down much. In addit

Re: Monoculture

At 2:25 PM -0700 9/30/03, Matt Blaze wrote: >I'd encourage the designer of the protocol who asked the original question >to learn the field. I am very glad that before I started the E communication protocol , I looked at the problems that exist

Re: Monoculture

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 compe

Re: Monoculture

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 c

Re: Monoculture

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

Re: Monoculture

"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

Re: Monoculture

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 > pitfall

Re: Monoculture

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 t

Re: Monoculture

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 yo

Re: Monoculture

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 implement

Re: Monoculture

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 person

Re: Monoculture

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 "y

Re: Monoculture

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 misinte

Re: Monoculture

John S. Denker wrote: 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.

Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"

Guus Sliepen <[EMAIL PROTECTED]> writes: > Compared with the entire TLS protocol it is much simpler, compared with > just the handshake protocol it is about as simple and probably just as > efficient, but as I said earlier, I want to get rid of the client/server > distinction. You can't get rid o

Re: Monoculture

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

Re: Monoculture

hi ( 03.09.30 20:39 -0700 ) [EMAIL PROTECTED]: > And, given the recent set of widely publicized flaws in openssl and > openssh, I think that concern about monoculture in cryptography > software is pretty damn well founded. except for the fact that these holes get fixed as opposed to the other fla

Re: Monoculture

> 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 di

RE: Monoculture

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. I confess I didn't realise there was a need. You see, it's not that it "doesn't seem to excite" [me] - it's just that, well,

Re: Monoculture

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-

Re: Monoculture

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

Re: Monoculture

[EMAIL PROTECTED] writes: > I would think that the cryptographers in question would be even more > frustrated that so few products were available, to tell you the truth, > and would therefore be eager to help when someone makes an honest > attempt. We do. We generally tell them to use the exis

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

Bill Frantz <[EMAIL PROTECTED]> writes: >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".

Re: Monoculture

On Tue, Sep 30, 2003 at 07:54:44PM -0400, Rich Salz wrote: > Yes, it sometimes sucks to be a newcomer and treated with derision unless you > can prove that you understand the current body of knowledge. We should > all try to be nicer. But surely you can understand a cryptographer's > frustration