Re: anonymous DH MITM

2003-10-02 Thread Ian Grigg
Steven M. Bellovin wrote:
 
 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 this logic is behind the decision by the
 TLS RFC writers to deprecate ADH.  Hence, talking
 about ADH in TLS is a waste of time, which is why I
 have stopped suggesting that ADH be used to secure
 browsing, and am concentrating on self-signed certs.
 Anybody care to comment from the TLS team as to what
 the posture is?)
 
 What's your threat model?  Self-signed certs are no better than ADH
 against MITM attacks.

I agree.  As a side note, I think it is probably
a good idea for TLS to deprecate ADH, simply
because self-signed certs are more or less
equivalent, and by unifying the protocol around
certificates, it reduces some amount of complexity
without major loss of functionality.

(AFAIK, self-signed certs in every way dominate
ADH in functional terms.)

 Until you understand your threat model, you don't
 have any grounds to make that decision.

I think we are in agreement on that!?

 MITM is certainly possible -- I've seen it happen.  The dsniff package
 includes a MITM tool, as do many other packages; at the Usenix Security
 conference a few years ago, someone intercepted all web-bound traffic
 and displayed a page All your packets are belong to us.


An appropriate security model for a security conference
might be to put a sign up at the door saying

All your assumptions are belong to us

At least that way everyone would be in tune with the
nature of the conference.

Anything that happens at the Usenix Security Conference
is, in my book, ruled out of ones regular, commercially
relevant threat model.  Same goes for demos in a Uni
student lab.

We all know it's possible.  The question is, should we
worry about it?  And, following on from Perry's method,
should we impose our own fears on others?

A threat must occur sufficiently in real use, and incur
sufficient costs in excess of protecting against it, in
order to be included in the threat model on its merits.


 Anyone on
 the same LAN (switched or unswitched) could have done the same.  If
 you're not on the same LAN, a routing attack or a DNS attack could
 result in the same thing, and those are happening, too, in the wild.


I know a couple of instances were posted maybe 6
months back.  What we need really is some sort of
repository of MITM attacks in the wild.  Costs
would be very useful too.

iang

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


Re: anonymous DH MITM

2003-10-02 Thread bear


On Wed, 1 Oct 2003, Ian Grigg wrote:

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.

DH is an open protocol; it doesn't rely on an initial shared
secret or a Trusted Authority.

There is a simple proof that an open protocol between anonymous
parties is _always_ vulnerable to MITM.

Put simply, in an anonymous protocol, Alice has no way of knowing
whether she is communicating with Bob or Mallory, and Bob has no way
of knowing whether an incoming communication is from Mallory or from
Alice.  (that's what anonymous means).  If there is no shared secret
and no Trent, then nothing prevents Mallory from being the MITM.

You can have anonymous protocols that aren't open be immune to MITM
And you can have open protocols that aren't anonymous be immune to
MITM.  But you can't have both.

Bear

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


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

2003-10-02 Thread Barney Wolff
On Wed, Oct 01, 2003 at 07:02:00PM -0700, bear wrote:
 
 Heh. You looked at my mail headers, didn't you?  Yes, I use pine -
 primarily *because* of that property.  It treats all incoming messages
 as text rather than live code.
 
 A protocol for text (as opposed to live code) requires compliant
 clients (ie, clients that don't do anything other than display the
 recieved messages).  As such, it's at least somewhat a social issue.

While I agree that text is far safer than html or a .exe, do you run
Pine on a dumb terminal, or in a window?  If the latter, escape
sequences which most folks would class as text can lead to remote
compromise.  There have been occasional bugs in terminal emulators,
in X and others.  TERM=vt100 is in some sense defining an interpreted
programming language, albeit a limited one.

That absolute safety is impossible does not excuse software from our
favorite vendor whose security model is all but impossible to fathom,
so I'm not at all disagreeing with your point.  I use Mutt.

-- 
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

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


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

2003-10-02 Thread lists
From: bear [EMAIL PROTECTED]

 Heh. You looked at my mail headers, didn't you?  Yes, I use pine -
 primarily *because* of that property.  It treats all incoming messages
 as text rather than live code.

BUGTRAQ in the last 3 years lists over 80 mails on pine - including
reference to this recently:
http://www.idefense.com/advisory/09.10.03.txt
which also appears in candidates on cve.mitre.org.
(Mitre seem to take unreasonable time in converting candidates to
definite problems unless I'm misunderstanding their website.)

 [HTML mail] can cause your machine, specifically, to make network
 connections to get graphics, style sheets, etc, and will not display

That could include web bugs for spammers.  I agree it's ridiculous to
read mail in a browser but a conventional MUA has risks too.

I write all mail to disk and view it with my favourite text editor.
This is convenient with practice.  Now I only want MUAs for sending
mail (it's worth it to get the correct references in my reply headers).

I use this script on one of my accounts where I accept HTML mail
(reluctantly from a hotmail user).
http://www.notatla.org.uk/SOFTWARE/text_lover_mail_filter.plx
The HTML conversion is done by lynx (confined by SubDomain).

This practice can result in running mimencode -u and metamail -w
on a few things.  It's not that common for a non-text message to get
past my procmail rules and have me choose to read it.

This is all pretty simple but certainly not mass-market.  I must order a
told you so rubber stamp for when my monocultural acquaintances get hacked.

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


Don't kill the messenger (was: Re: Reliance on Microsoft called risk to U.S. security)

2003-10-02 Thread Roy M. Silvernail
On Wednesday 01 October 2003 22:02, bear wrote:

 No, it is not.  You can make a hyperdocument that is completely
 self-contained and therefore text, but that is not how HTML is
 normally made.  HTML can cause your machine to do things other than
 display it, and to that extent it is code, not text.

A small nit: HTML is, in fact, text.  The effects you describe are the result 
of a client taking certain actions based on the text/html MIME type.  That's 
the reason you use Pine (and I use Kmail).  These clients (and others... yay, 
elm!) don't take unbidden actions to render HTML mail or cause executable 
attachments to execute.

 You can't rely on saving an HTML document
 and being able to read it years or decades later, because with
 hypertext, maybe the part you're interested in (or need for evidence)
 isn't even on the page you saved.

True, but again, that's a property of HTML. That the HTML document was 
transmitted through mail is a side issue.

It's not that email has been overloaded, through the use of MIME, to carry 
content other than text/plain.  The problem is that certain MUAs have been 
built to take some default actions based on the MIME types received, and 
those clients have become (for whatever reason) popular among mail users of 
a, shall we say, non-technical bent.

 The fact that sending HTML (and other code) through SMTP was not
 considered a violation of SMTP has allowed a generation of mail
 readers to become common that encourage mail viruses, macroviruses,
 worms, and other malicious code.  If we are interested in security, we
 need some kind of protocol where we as a group just draw a line and
 say nothing but text through this port.

SMTP is *already* such a protocol.  Base-64 encoding (and UUENCODE before it) 
was designed to address the 7-bit gateway through which email once passed.  
MIME only describes and encapsulates non-textual content.  (the first M 
originally stood for 'multimedia', not 'multipurpose') Some mail clients have 
evolved (or been designed *cough*outlook*cough*) to be infection vectors, but 
that's not the fault of the base transport protocol.  It's the result of poor 
security decisions in the client design process.

This is not to demonize MIME, either.  Some applications, like PGP signatures, 
are elegant uses. Much better than the X-PGP-Signature header I was helping 
develop 10 years ago.  There's nothing intrinsically wrong with extending 
mail to carry arbitrary content.  The problem appears when the MUA is able to 
take some risky action with that content, whether automatically or through 
unwise user action.  Grandma clicks on everything.

Mail as a vulnerability is a client issue and a training issue.

That said, I also despise HTML mail for all the reasons you describe.  But 
between the September That Never Ended and the release of Mosaic, it's really 
no surprise that eye candy has become an imperative.

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


Re: Monoculture

2003-10-02 Thread Dave Howe
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 in place [1].

 I don't think the jury has reached an opinion on why
 the cryptography group looks like a guild as yet,
 and it may never do so.  A guild, of course, is either
 a group of well-meaning skilled people serving the
 community, or a cartel for raising prices, depending
 on who is doing the answering.
To me it seems more like a academic community - particularly the way many
can't handle the concept of good enough but look for theoretically
perfect solutions that may be unworkable in the Real World.  And yes, I
*am* an outsider - I dabble a little, and I am a programmer, but I am the
first to admit my math skills are nowhere near adequate to make any
meaningful contribution to the field.
It seems to me there is no more a cryptography guild than a linux guild -
yes, you get advocates who foam at the mouth if you say the wrong thing,
but the majority seem more interested in getting it to work.  From my POV
as a programmer, learning the field consists of identifying the
available building blocks (hash, symmetric, asymmetric), standards
(openpgp, x509, ssl, ssh, ipsec) and prior implimentations (paying
particular attention to what had to be patched due to discovered
vunerablities, so as to avoid the same errors in my own code)
It also seems the crypto community is very open to questions, very hostile
to statements - so often knowing how to phrase something to them is as
important as the content of the question. Stating I am doing $FOO will
not be as productive as If I were to do $FOO what vunerabilities would
that introduce? - remembering that any good advice you get back for free
would have probably cost you weeks of study or possibly thousands of
dollars trying to obtain a security certification for your solution later
on.
Just ignore any posts of because it isn't done that way unless they give
a good reason why your way isn't better (note as good isn't good
enough - you always need a good reason to stray from a tested and known
path, and it is often worth putting up with a few minor inconveniences to
stay on it)
Oh - and make sure you can recognise a good reason when you see it ::)

 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 those protocols that went before them.  The
 guild would like the builder to present his protocol and
 hope it be taken seriously.  The guild would like the
 builder of applications to reach acceptable standards.
I would certainly expect a house builder to know how to lay bricks - but
if he insisted on designing the house too, I would expect him to know how
to do that (and not just start putting up walls and hoping it will all
work out later.
Design requires a fair understanding of what you are designing and what
the capabilities and limitations of the materials are - this is why SAs
get paid more than their programming teams (not that I like that given I
am a programmer not a SA).  If you aren't willing to learn how to do that,
you can still follow someone else's design - or take a modular approach
and just drop pre-built units (normally libraries) into those parts of the
code that need them. Libraries can be surprisingly good - if the designer
put in enough effort, they can have sufficient inline M/C for the
timing-critical parts that they are noticably more efficient than
implimenting your own code in a medium or high level language.

 And, the guild would like the builder to take the guild
 seriously, in recognition of the large amounts of time
 guildmembers invest in their knowledge.
That does tend to happen - in any community, you get those who get used to
being authorities, and react badly to being challenged. At least in this
community most of them have the sense to back down when proved wrong :)

 None of that is likely to happen.  The barrier to entry
 into serious cryptographic protocol design is too high
 for the average builder of new applications [2].  He has,
 after all, an application to build.
Indeed so - that is why using a prebuilt standard (or better yet, a
library) as your base is such a good idea. However, a lot of programmers
don't like doing that because
they feel it is either cheating or means all their hard work is going to
be dismissed as just an implimentation of someone else's idea rather
than something original and novel.  However, the odds of someone rolling
their own protocol getting something more efficient or effective as work
that has already been done are low - and if the package you put together
is sufficently good, no users will care it uses SSH (protocol) for comms
or someone else's AES library for 

RE: Monoculture

2003-10-02 Thread Don Davis
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) with a yes, in which case I will /definitely/
 get on with recoding SSL:
 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?)

how it's done depends on the browser:

in Moz 1.0:  Edit  Preferences...  Privacy  Security 
 Certificates  Manage Certificates 
{Authorities, Web Sites}

in MSIE 5:   Edit  Preferences..,  Web Browser 
 Security  Certificate Authorities

(there seems to be no way to tell MSIE 5 to
 trust Alice's server cert for SSL connections,
 except to tell MSIE 5 to trust Alice's CA.)

in NS 4.75:  Communicator  Tools  Security Info 
 Certificates  {Signers, Web Sites}

- don davis, boston







-

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


Re: VeriSign tapped to secure Internet voting

2003-10-02 Thread Anton Stiglic
 Schu stressed that several layers of security will prevent hackers from
 accessing the system. VeriSign will house the security servers in its own
 hosting centers. The company will ask military personnel to use their
 Common Access Cards--the latest form of ID for the military--to access
 the system and cast a vote. Civilians will use digital signatures.

So how will these civilians get a certified public key, and how will the
private
key be protected?  Is there a special policy for the issuance of these kind
of certificates?

--Anton

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


Re: Monoculture

2003-10-02 Thread Dave Howe
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 want to write a grep tool/compiler/editor/whatever - he
wanted to write hurd. however, he recognised that hurd needed to be *built
on* a solid foundation of tools and resources; most people have never
heard of hurd, but use directly or indirectly something in the gnu toolbox
every day (mostly without knowing it)
if you build a decent TLS library, then build a VPN daemon to use that
library, you have contributed both a daemon and a TLS library, and
thousands of people may well use the TLS library without needing or
wanting a VPN daemon (given a TLS library is of much more general use than
a vpn daemon)


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


RE: Monoculture

2003-10-02 Thread Jill Ramonsky
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++ implentation with classes and templates and stuff. (By 
contrast OpenSSL is a C implementation). Anyone got any thoughts on 
that? Also - anyone thinking of using something like this - could you 
post (in another thread maybe) suggestions as to what kind of simple 
interface you actually want? As in, what you want it to do? All 
suggestions gratefully considered, but in the light of comments in this 
list, I will /not/ turn it into bloatware just to satisfy all demands. 
(OpenSSL can do that). Finally - I'll need some help setting up a 
sourceforge thing as I've never set up an open source project before and 
don't really know how to go about that. Some advice on licensing 
wouldn't go amiss either. (GPL? ... LGPL? ... something else?)

Re Don's comments below:

This seems to me to a /serious/ flaw in the design of MSIE. What if 
Alice doesn't /have/ a CA because she can't afford their fees? (or she 
doesn't trust them, or for any other reason you might care to think of). 
In fact, if I've understood this correctly, if Alice uses MSIE, she 
can't even tell her browser to trust her own website, despite being in 
possession of not only her own public key, but her own secret key as 
well! What is it with MSIE that it would prefer to trust someone other 
than Alice about the authenticity of Alice's site !!!???

Okay guys - _this is a serious question_. Alice has a web site. Alice 
has a web browser which unfortunately happens to be MSIE. Alice wishes 
to view Alice's web site using Alice's browser (which is not on the same 
machine as the server). Alice does not wish to trust ANYONE else, but 
she does trust herself absolutely. How does she get the browser to 
display the padlock?

I wouldn't be at all surprised if the answer turns out to be It can't 
be done. (That may not be a problem if other browsers don't have this 
design flaw, of course, 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 to
  (b) to trust Alice's certificate  (which she handed
  to him personally)? (And if so, how?)

 how it's done depends on the browser:

 in MSIE 5:   Edit  Preferences..,  Web Browser 
  Security  Certificate Authorities

 (there seems to be no way to tell MSIE 5 to
  trust Alice's server cert for SSL connections,
  except to tell MSIE 5 to trust Alice's CA.)

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


Speciality film heads meet to respond to MPAA

2003-10-02 Thread R. A. Hettinga
Paul Kocher quote at the bottom...

Cheers,
RAH
---

http://www.hollywoodreporter.com/thr/article_display.jsp?vnu_content_id=1991585

The Hollywood Reporter

Oct. 02, 2003 

Speciality film heads meet to respond to MPAA 

By  Gregg Kilday 
The MPAA may have hoped to create a nonproliferation treaty with its ban on 
awards-season screeners, announced Tuesday, but instead it set off a veritable bomb 
that sent shock waves throughout the film community. 

The heads of most of the studio-based specialty film companies met Wednesday in an 
unprecedented summit at the Four Seasons Hotel in New York to formulate a response. 

Bingham Ray, president of United Artists, MGM's specialty film division, took the lead 
in organizing the gathering, which brought together top executives from all the 
studio-affiliated labels except Fox Searchlight and the newly formed Warner 
Independent Pictures. (Fox Searchlight execs were later updated on the proceedings.) 

Those present or participating by phone are said to have included Miramax Films' 
Harvey Weinstein, Focus Features' David Linde and James Schamus, Sony Pictures 
Classics' Tom Bernard, and Fine Line's Marian Koltai-Levine. 

The group, with Ray acting as its spokesman, is expected to issue a statement today or 
Friday. Ray was unavailable for comment Wednesday. 

It was the beginning of a dialogue, said one indie exec, who received reports of the 
meeting. All of the indie companies have been getting a lot of questions and concerns 
from film critics, foreign distributors, foreign partners, exhibitors, artists -- 
writers, directors, actors -- and talent agencies, and there has been a lot of 
discussion. 

Another source close to the situation said: I think it was a historic meeting with 
some pretty incredible minds. It was really more of a study group. They were asking a 
lot of questions. 

One approach that the group could take was suggested by a separate statement released 
Wednesday by Michelle Byrd, executive director of the IFP/New York. 

Signed by 33 filmmakers, producers and executives, the statement condemned the MPAA 
ban. 

This last-minute policy change will seriously diminish the diversity and quality of 
independent films immediately and the mainstream film industry in the long run, the 
statement read. Oscar consideration is a primary motivating factor behind the funding 
of riskier films, those of more serious content, films with ambitious narrative 
aspirations. Lacking Oscar potential, these films will not be made. 

It noted that the least likely people to pirate -- Academy members and other insiders 
-- will suffer the most, particularly since most piracy comes from outside the U.S. 
and is the result of in-theater taping. The group proposed in the statement that all 
screeners (both DVD and VHS) ... be watermarked and individually numbered so they can 
be traced and the perpetrators prosecuted. 

Among those lending their names to the statement, which was still growing at press 
time, were directors Robert Altman, Bill Condon, Peter Hedges and John Waters; actors 
Selma Blair, Hilary Swank, Chloe Sevigny and Tracey Ullman; producers Anthony Bregman, 
Lee Daniels, Ted Hope, Ross Katz, John Penotti and Christine Vauchon; and execs 
Johnathan Sehring and Ed Pressman. 

Byrd explained that Hope, producer of American Splendor, brought his concerns first 
to her and others, such as Greenestreet Films' John Penotti, and Focus' Linde quickly 
weighed in. 

The chief challenge facing independents is always one of access, she said. Access 
to screens, distributors and, in this case, Academy voters. We want to ensure that 
these films are given a fighting chance in terms of recognition. 

Meanwhile, in other fallout from the MPAA decision: 

The MPAA issued a clarification to its member companies on one point. Although a 
number of Oscar consultants believed the ban, as originally stated, would have allowed 
them to distribute DVDs of films that would be available in the home video market -- 
for example, Disney/Pixar's Finding Nemo or the Universal release Seabiscuit -- 
the MPAA shut down that loophole. 

It has been reported that some subsidiaries believe it is OK to send out screeners if 
the film has been released in home video form, the clarification said. This is 
incorrect. The policy is no screeners of any kind are allowed to be sent. 

It was found that DVD mastering facilities such as Cinram, Deluxe, Sonopress, 
Technicolor and Warner Bros.' WAMO have been working for months with the studios to 
develop and implement forensically trackable DVD technologies specifically for the 
upcoming awards season. 

We've been working with the studios for the past year in developing antipiracy 
technologies, said a disc replication manager, who wished to remain anonymous. About 
six to eight months ago, two studios actually came to us and said, 'Hey, we foresee 
this being a problem, can you help us develop a solution?' The studios are very aware 

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

2003-10-02 Thread Jerrold Leichter
|  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.
While I agree with the sentiment, the text/code distinction doesn't capture
what's important.

Is HTML text or code?  Well ... it's actually neither.  There is a set of tags
in HTML that is perfectly safe.  Setting fonts and font colors, describing a
table ... all kinds of stuff like that isn't text, but it can't hurt you
either.  (Whether these are *useful* in mail is a whole other question)
On the other hand, embedded references that reach out over the network are
inherently dangerous, since the very act of autonomously opening a connection
to a system of someone else's choosing is something I, personally, don't want
my mail reader doing, ever.

Text is code, too!  A plain ASCII message received by Pine is run through the
Pine Interpretation Engine - the Pine MUA under another name.  Some character
sequences cause entries to be made into a list of subject lines.  Others
may trigger automatic refiling.  Most cause bits to be written to a terminal
window.  Those bits in turn are really code, interpreted by my xterm (or
whatever), causing it do to all kinds of complicated things that ultimately
light some pixels on my screen.

The real distinction is:  Which of *my* resources are *you* able to manipulate
by sending me mail?  I'm willing to give you complete access to send characters
to the terminal in which pine runs ... well, almost.  There's a long history
of security holes *in terminals* - e.g., escape sequences that load the WRU
buffer, and then a control character that causes the WRU to send back
qyy|rm *\n!  You have to carry this analysis *all the way through all the
levels of interpretation*.  Way back, when I worked on designing terminals at
DEC, we were aware of the security issues and it was a design rule that there
was no way to send characters to the terminal and have exactly those read back
automatically.  (Usually, you couldn't read it back at all.  Otherwise, they
were wrapped up in a format that would be innocuous to all but very strange
programs - e.g., as a hex string.)  It was fun evaluating competitor's
terminals against that design rule - almost all of them failed.  (It was not
so much fun telling marketing that no, we would not implement that particular
feature even though the competition had it.)

Anyhow ... if you consider the entire *system*, then the rule is that I will
give you complete access to write a certain safe subset of ASCII characters,
or a safe subset of ASCII characters plus escape sequences.  That's why mail
clients have long filtered out certain characters.  (An MUA that talks direct
X calls has no reason to filter anything, since writing a text string directly
with X goes into an interpreter that can change *only* the bits on the
screen.)

A resource-based model gives you some basis for deciding which parts of HTML
are acceptable, and which are not.  Given such a model, it's perfectly
possible to write a safe HTML interpreter.  Of course, you lose some features -
that's life.  Life would also be much easier if you never had to lock your
door because no one would ever think of stealing.

BTW, a resource model has to change with time.  The traditional view has been
that I grant anyone full write access to the end of mail file - i.e., anyone
can send me as much mail as they like.  These days, I really *don't* want to
grant that access to spammers - and spam blocking techniques are all about how
to control the SMTP interpreter I present to the outside world to protect
my disk resources.
-- Jerry

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


Return of the death of cypherpunks.

2003-10-02 Thread R. A. Hettinga

--- begin forwarded text


Status:  U
From: James A. Donald [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed, 1 Oct 2003 23:37:08 -0700
Subject: Return of the death of cypherpunks.
Sender: [EMAIL PROTECTED]

--
When a mailing list is full of crap, it dies, even though the  
regulars set killfiles to silence the offending posters.  The  
reason is, no new people arrive.

New people subscribe, see nothing but crap, unsubscribe.

A mailing list or newsgroup needs a strong personality who is a 
prolific poster who keeps discussions on track, issues lots of 
good stuff, and reprimands trolls and nuts.  That person, of   
course was Tim May.  (past tense)

It also needs a continual stream of new people, who bring new  
ideas, and unfamiliar ways of recognizing old ideas.

The relentless mass spamming by professor rat and Jim Choate   
keeps new comers away, since 99% of the posts to the list is   
from people who hate the ideas that the list was created to
further, and seek to shut it down, to prevent thought about and 
discussion of such ideas, and Tim May has succumbed to terminal 
grumps on discovering that the crypto transcendence is not
coming soon.

So when is the crypto trancendence coming?  When does an
encryption enabled internet start to undermine the power of the 
state?

Well it is a little like web groceries.  During the Dot.com
hype, lots of web grocery companies popped up, and made about a 
cent on the dollar.  They vanished, but, surprise surprise,
there are now some real web grocery firms,  and they are
making a little bit of money.

Darknet (frost over freenet) is going tolerably well, mostly in 
its Japanese incarnation, the repression being stronger in
Japan.  The Japanese experience tells us that any repression   
short of communist levels of repression will make darknet
stronger, not weaker.  The big threat to frost over freenet is 
the natifying of the net which makes more and more people into 
clients, not peers.   Theoretically frost over freenet serves   
even those behind NATs, but really it does not, and cannot.

Private money on the internet remains a small, non anonymous,  
backwater.

There is no Chaumian anonymity.  There is some trust us
anonymity, located on offshore islands, controlled by people   
quite susceptible to US pressure.

Account based money without true names or the mark of the beast 
is a tiny but profitable business.  E-gold is probably the
largest player, with about two million dollars a day changing  
hands, and twenty thousand micropayments a day (payments of
less than a dollar)

Two million a day is one five hundred thousandth of the 
turnover on the US$, and it is not growing very fast.  Of
course e-gold is just one of several, but it probably a large  
portion of the total.

Suppose no-true-name account based money grows at thirty
percent a year, which seems plausible.  In due course
some substantial portion of it will be chaumian.

Then the US$ goes into crisis in 2060. As Adam Smith put it,   
There is a lot of ruin in a nation..

Even if we suppose that the institutions of the crypto
trancendence undergo remarkably rapid growth, the kind of
growth that the dot bombs predicted in their business plans,   
the crypto trancendence does not hit until around 2025.

But right now today, the internet is undermining the power of  
the state.  The Japanese government went as far as democracy   
can go, and perhaps a bit further, to shut down file sharing.  
The result:  Widespread adoption of software based on freenet. 
Cypherpunks 1, state 0.  We have a long way to go, but we are  
going.

Oh yeah, and once again I declare the mailing list that gave  
the name of this movement to be dead, though the fact that I am 
still posting on it would seem to prove it is alive, though
breathing its last.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 dcuOonOpNgPgqZpgbJF0j6ClGa0j1it1Uk51kc/Q
 4Nnby2D6L0GGqj2rwXsyWpY1xoKh901QBG9bsYjxG

--- end forwarded text


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
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]


Re: anonymous DH MITM

2003-10-02 Thread Zooko O'Whielacronx

 Bear wrote:

 DH is an open protocol; it doesn't rely on an initial shared
 secret or a Trusted Authority.
 
 There is a simple proof that an open protocol between anonymous
 parties is _always_ vulnerable to MITM.
 
 Put simply, in an anonymous protocol, Alice has no way of knowing
 whether she is communicating with Bob or Mallory, and Bob has no way
 of knowing whether an incoming communication is from Mallory or from
 Alice.  (that's what anonymous means).  If there is no shared secret
 and no Trent, then nothing prevents Mallory from being the MITM.
 
 You can have anonymous protocols that aren't open be immune to MITM
 And you can have open protocols that aren't anonymous be immune to
 MITM.  But you can't have both.

I'd like to see the proof.

I think it depends on what you mean by MITM.  Take the Chess Grandmaster 
Problem: can Alice and Bob play a game of chess against one another while 
preventing Mitch (the Man In The CHannel) from proxying their moves to one 
another while taking the credit for being a good chess player?

To make it concrete, suppose we limit it to the first two moves of a chess 
game.  One player is going to make the first move for White, and the other 
player is going to make the first move for Black.

Now, obviously Mitch could always act as a passive proxy, forwarding exactly 
the bits he receives, but in that case he can be defeated by e.g. DH.  To make 
it concrete, suppose that the first player includes both his move and his 
public key (or his public DH parameters) in his message, and the second player 
encrypts his message with the public key that arrived in the first message.

Mitch wins if the first player accepts the second player's move (the first 
move for Black).  The players win if the first player accepts a different move 
that the second player didn't make.  (This is the case where Mitch is no 
longer doing the Chess Grandmaster Attack, but is instead just playing two 
games of chess, one game with the first player and another game with the 
second player.)

If the players reject a message and end the protocol, then neither Mitch nor 
the players win -- it is a tie.  (A denial-of-service situation.)

Now, you might intuitively believe that this is one of those situations where 
Mitch can't lose.  But there are several protocols published in the literature 
that can help the players against Mitch, starting with Rivest  Shamir's 
Interlock Protocol from 1984.

The funny thing is that all of these published protocols seem to require a 
constraint on the game of chess.  For example, the Interlock Protocol works 
only with full duplex games where both sides are making a move at the same 
time.  You can't obviously apply it to chess, although you *could* apply it to 
a full-duplex game like chess variant Bughouse, or, um, children's card 
game War.  Or a Real-Time Strategy computer game where both players are 
sending moves to one another simultaneously.

Now, you might go back to the beginning of this message and say Well, Chess 
Grandmaster isn't MITM!.  In that case, I would like to see a definition of 
what exactly is this MITM which can't be countered in the no- shared-trust 
setting.  I'm not saying that there isn't such a thing -- indeed I can think 
of a definition of MITM which satisfies that requirement, but I'm not sure 
it is the same definition that other people are thinking of.

Anyway, it is a funny and underappreciated niche in cryptography, IMO.  AFAIK 
nobody has yet spelled out in the open literature what the actual theoretical 
limitations are.


Regards,

Zooko

http://zooko.com/log.html

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


Re: Monoculture

2003-10-02 Thread Thor Lancelot Simon
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++ implentation with classes and templates and stuff. (By 
 contrast OpenSSL is a C implementation). Anyone got any thoughts on 

A C++ implementation will be much less useful to many potential users;
perhaps the most underserved set of potential SSL/TLS users is in the
embedded space, and they often can't afford to, or won't, carry a C++
runtime around with them.  We learned this lesson with FreSSH and
threads.

I would strongly recommend a C implementation with an optional C++
interface, if C++ is the way you want to go.

Also, I'd consider, for simplicity's sake, at least at first, implementing
*only* TLS, and *only* the required ciphers/MACs (actually, using others'
implementations of the ciphers/MACs, even the OpenSSL or cryptlib ones,
is probably not just acceptable but actually a _really good idea_.)  The
major problems with OpenSSL are, from my point of view, caused by severe
overengineering in the areas of:

1) Configuration
2) ASN.1/X.509 handling
3) Tightly-coupled support for the many diverse variants of SSL/TLS.

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 and then think hard about
what people actually use SSL/TLS for in the real world.  It's horrifying
to note that OpenSSL doesn't even have a published interface for a some of
these operations.  For example, there is no simple way to do the most
common certificate validation operation: take a certificate and an optional
chain, and check that the certificate is signed by an accepted root CA, or
that each certificate in the chain has the signing property and that the
chain reaches that CA -- which would be okay if OpenSSL did the validation
for you automatically, but it doesn't, really.

From my point of view, a _very_ simple interface that:

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's
   probably a good idea to require the application to explicitly
   do another function call validating the connection if it decides to
   continue despite an identity mismatch; this will avoid a common,
   and dangerous, programmer errog.

4) Provides select/read operations thereafter.

Would serve the purposes of 90+% of client applications.  On the server
side, you want a bit more, and you may want a slightly finer-grained
extended interface for the client, but still, you can catch a _huge_
fraction of what people do now with only the interface listed above.

Thor

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


Re: anonymous DH MITM

2003-10-02 Thread Tim Dierks
At 11:50 PM 10/1/2003, Ian Grigg wrote:
(AFAIK, self-signed certs in every way dominate
ADH in functional terms.)
In TLS, AnonDH offers forward secrecy, but there are no RSA certificate 
modes which do (except for ExportRSA). You can use ephemeral DH key 
agreement keys with static certified DSA keys, though.

To be clear, this is a protocol issue, not really a self-signed certs vs. 
DH issue. The only real difference between a self-signed cert and an 
ephemeral bare public key is that you've got proof of private key 
possession by somebody (if that matters to you), and the entity has bound a 
self-asserted name  attributes to the key. Also, our extant infrastructure 
makes it easier to cache a once-presented X.509 certificate for consistency 
with future transactions, and self-signed certs fit more cleanly into a 
hybrid model where some entities are trusted due to third-party 
certification and some are directly approved.

 - Tim

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


Re: Monoculture

2003-10-02 Thread Simon Josefsson
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
 daemon. 

 Well, then you might consider using an existing TLS library. It is
 rather hard to make a protocol that does TLS things that is both safe
 and in any significant way simpler than TLS.

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.

I have to agree with many things in the paper; using TCP (as TLS does)
to tunnel TCP/UDP is a bad idea.  Off-the-shelf TLS may be a good
security protocol, but it is not a good VPN protocol.  Recommending
TLS without understanding, or caring about, the application domain
seem almost arrogant to me.

Admittedly, you could invent a datagram-based TLS, but this is not
widely implemented nor specified (although I vaguely recall WTLS) so
then you are back at square one as far as security analysis goes.

Thanks,
Simon

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


Re: Monoculture

2003-10-02 Thread Perry E. Metzger

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, but if
people aren't going to use ipsec they should at least use a protocol
that isn't insecure.

Perry

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


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

2003-10-02 Thread Bill Frantz
Peter has raised a number of important points.  Let me start by saying that
I do not see a strong distinction between a file to be viewed and a
program.  Both are instructions to the computer to perform some actions.
While we might think the renderer showing us flat ASCII text is quite
trustworthy, our degree of trust in an HTML should be less, and we
shouldn't trust a Word format renderer at all (thanks to Word Macro
viruses).

At 9:21 PM -0700 9/30/03, Peter Gutmann wrote:
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.

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.

I do not envision running either programs or viewers under the privileges
of the mail agent.  Since I am not really a Unix person, let me take a stab
at a design and let the people who know what they are doing take stabs at
it.

What we need is an environment of very limited privilege to use to confine
our untrusted code.  Specifically:

* No ability to make connections to other services, either over the network
or locally.  (I think this item requires a kernel change.)

* Very limited access to the file system.  We might take the view that
since we control all the ways the confined process can send data out of the
system, it can have full read-only access to the file system without
risking anything important.  I am told we can build general limits of file
system access with chroot, but I am also told that processes can break out
of these limits.  This is an area where I would love to learn more.

* We can pass in the privileges we think the process should have via open
file handles.  These will probably include the ability to render on a
portion of the screen, and the ability to get mouse and keyboard focus.
(We need a way for trusted code to mediate these accesses so the user can
have a secure attention function.)

* Strict control of other communication paths I haven't thought of.  :-)


In addition everyone's sending you HTML-formatted mail, so you
need access to (in effect) MSIE via the various HTML controls.

An HTML renderer should be able to run in the above environment.


Further, you
need Word and Excel and Powerpoint for all the attachments that people send
you.

For viewing Word etc. documents, the applications should run in the above
environment.  The interesting case is where someone has sent you something
like a Word document and asked you to mark it up.  Everything should
proceed well in the above until it comes time to save a local copy or mail
the changed document back.

http://www.combex.com/papers/darpa-report/html/ describes the Powerbox
pattern for allowing the user to specify an output file for a confined
process such as we are discussing.  I would think the best way to return
such a file in Unix would be as an open file handle.  However I don't know
of a way for a program to call a service with greater privilege than it has
and accept a return value unless that service is part of the kernel.
Perhaps some Unix experts can come up with ideas.

As for mailing the document back, if the mail agent gave the confined
program read-write access to a copy of the file, the confined program could
write its output over the input and the mail agent could then make that
file available to the user when the confined program returns, and the user
could include it in the reply email.


They need access to various subsystems like ODBC and who knows what else
as an extension of the above.

Since most users do not have these facilities running on their machines, I
suspect that most Word/Excel/Powerpoint files would render quite well from
a confined process.  I would say that having random, perhaps hostile, files
able to update my local data bases is a violation of my security policy.


As you follow these dependencies further and
further out, you eventually end up running what's more or less an MLS system
where you do normal work at one privilege level, read mail at another, and
browse the web at a third.  This was tried in the 1970s and 1980s and it
didn't work very well even if you were prepared to accept a (sizeable) loss of
functionality in exchange for having an MLS OS, and would be totally
unacceptable for someone today who expects to be able to click on anything in
sight and have it automatically processed by whatever app is assigned to it.

UIs have changed considerably since the 1980s.  It turns out that modern
UIs make it much easier for users to run programs with only the privileges
they need than the UIs of the 80s.  (See the email thread at

Re: anonymous DH MITM

2003-10-02 Thread Zooko O'Whielacronx

 Bear wrote:

 If it's an anonymous protocol, then credit for being a good chess
 player is a misnomer at best; the channel cannot provide credit to
 any particular person.

I understand the objection, which is why I made the notion concrete by saying 
that Mitch wins if he gets the first player to accept the second player's 
move.  (I actually think that you can have some notion of credit -- for 
example a persistent pseudonym linked to a longer-term public key, but that 
isn't necessary to appreciate the current challenge.)


  Now, obviously Mitch could always act as a passive proxy, forwarding
  exactly the bits he receives, but in that case he can be defeated by
  e.g. DH.  To make it concrete, suppose that the first player
  includes both his move and his public key (or his public DH
  parameters) in his message, and the second player encrypts his
  message with the public key that arrived in the first message.
 
 Public key? I thought we were talking about an open protocol between
 anonymous entities.  If Alice and Bob can identify each other's public
 keys, we're not talking about anonymous entities.

Right.  I proposed that the first player send a public key even though the 
second player has no way to authenticate it.  The effect of this is that Mitch 
can no longer act as a purely passive proxy (i.e., he can't act like an Eve), 
because if he does the second move will be encrypted so that he can't read 
it.  Oh -- whoops!  This doesn't suffice to deter Mitch from acting as a 
passive proxy, since we didn't specify that he had to actually see the second 
move in order to win.  Maybe we should add the requirement that for Mitch to 
win he has to know what the second player's move was.

Sorry about the incorrect detail.


  Now, you might intuitively believe that this is one of those
  situations where Mitch can't lose.  But there are several protocols
  published in the literature that can help the players against Mitch,
  starting with Rivest  Shamir's Interlock Protocol from 1984.
 
 Hmmm.  I'll go read, and thanks for the pointer.  But I'm confident
 that if Mitch can be kept out, then either it's not fully anonymous
 participants, or it's not a fully open protocol.

I understand where you are coming from.  Your intuition about this is usually 
right (i.e., for pretty much all protocols that you have ever actually 
encountered), and it is an intuition that you share with most thinkers, even 
those who are brilliant and well-read cryptographers.  However the Interlock 
Protocol provides a counter-example to that intuition!  (Not for Chess 
Grandmaster, but for a full-duplex protocol such as Bughouse Grandmaster).

There are other counter-examples in the literature, which I would be happy to 
enumerate.  :-)


Please let me know if you find an on-line copy of Rivest  Shamir Interlock 
Protocol 1984.  I had to walk down to a library to read it.

Regards,

Zooko

http://zooko.com/log.html

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


Re: anonymous DH MITM

2003-10-02 Thread Tim Dierks
At 11:52 AM 10/2/2003, Zooko O'Whielacronx wrote:
 Bear wrote:
 You can have anonymous protocols that aren't open be immune to MITM
 And you can have open protocols that aren't anonymous be immune to
 MITM.  But you can't have both.
I'd like to see the proof.

I think it depends on what you mean by MITM.  Take the Chess Grandmaster
Problem: can Alice and Bob play a game of chess against one another while
preventing Mitch (the Man In The CHannel) from proxying their moves to one
another while taking the credit for being a good chess player?
I think it's a tautology: there's no such thing as MITM if there's no such 
thing as identity. You're talking to the person you're talking to, and 
that's all you know.

Re: your chess problem, I think the reason it's not applicable is because 
the concept of Alice and Bob, as distinct from Mitch, has no role in 
an anonymous protocol: Alice completing a chess move with Mitch is just as 
valid as completing one with Bob.

 - Tim

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


Re: anonymous DH MITM

2003-10-02 Thread Ed Gerck


bear wrote:

 You can have anonymous protocols that aren't open be immune to MITM

True.

 And you can have open protocols that aren't anonymous be immune to
 MITM.

True.

 But you can't have both.

False. In fact, it is possible  to prove the existence of at least one open and
anonymous protocol that is immune to MITM in any given, feasible scenario
(ie, given a threat model).

Cheers,
Ed Gerck

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


Re: Monoculture

2003-10-02 Thread Bill Frantz
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 advance such arguments
were electrocuted or killed in fires before they had a chance to make
their case).

In most of the US, a homeowner can install electrical systems in their
house.  However, their installation must be up to code, and inspected by a
government inspector.  The analog for crypto protocols seems to be obvious,
although the inspector part seems to be more ad hoc and community based.
(But there's no building permit either.)

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]


crypto licence

2003-10-02 Thread Ian Grigg
Guus Sliepen wrote:

  Some advice on licensing wouldn't go amiss either. (GPL? ... LGPL? ...
  something else?)
 
 I'd say LGPL or BSD, without any funny clauses.

With crypto code, we have taken the view that it
should BSD 2 clause.  The reason for this is that
crypto code has enough other baggage, and corporates
are often the prime users.  These users are often
scared very easily by complex licences.

We'd tended to vacilate somewhat with applications,
between various Mozilla/Sun community models, but
with the underlying crypto, always as free as possible.

If you wanted to be in the GPL community, then LGPL.
GPL itself will infect any apps, so unless you have
a really great belief that you want those users and
no others, stick to LGPL.

Mind you, those have been our experiences.  It's
quite plausible that we'd have attracted a bigger
developer base simply by going GPL.

iang

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