Re: Anyone Remember Zero Knowledge Systems?

[Adam Shostack]

On Wed, Sep 10, 2003 at 11:32:29AM -0400, R. A. Hettinga wrote:
| 
| 
| Cryptonomicon.Net - 
| 
| Anyone Remember Zero Knowledge Systems? 
| Date: Wednesday, September 10 @ 11:15:00 EDT 
| Topic: Commercial Operations / Services 


| Unfortunately, they never quite made a compelling enough argument
| for mass adoption of their system and eventually morphed the company
| into a manufacturer or more conventional privacy tools. Freedom still
| exists as a product, thought it is aimed at web users, only runs on
| Windows clients, and routes requests through proxy servers owned by
| Zero Knowledge Systems.   


Freedom Websecure is a different protocol set from Freedom.net.

Websecure runs on linux, see http://websecure4linux.sourceforge.net/

The Freedom.net code is available for non-commercial use, see
http://slashdot.org/articles/02/02/16/0320238.shtml?tid=158 or the
shmoo group cvs server,
http://cvs.shmoo.com/view/projects/freedom-server/

The problem with running Napster over Freedom was bandwidth costs.
Users may be more willing to pay today, given the clear risk of paying
$10,000 or more in fines.  I'm sure that ZKS would be happy to sell
someone a commercial use license.

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
   -Hume



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

[Isig] Re: Boston Linux Meeting Wednesday, September 17, 2003 PGP/GnuPG Keysigning Party

[R. A. Hettinga]

--- begin forwarded text


Status:  U
From: Jerry Feldman <[EMAIL PROTECTED]>
To: BLU <[EMAIL PROTECTED]>, CONE <[EMAIL PROTECTED]>,
GNHLUG <[EMAIL PROTECTED]>, ISIG <[EMAIL PROTECTED]>,
New England Information Security User Group <[EMAIL PROTECTED]>
Organization: Boston Linux and Unix
Subject: [Isig] Re: Boston Linux Meeting Wednesday, September 17, 2003 PGP/GnuPG
 Keysigning Party
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
List-Help: 
List-Post: 
List-Subscribe: ,

List-Id: Boston Internet Special Interest Group(ISIG) 
List-Archive: 
Date: Wed, 10 Sep 2003 14:59:24 -0400

When: Wednesday, September 17, 2003 7:00 PM (6:30 for general Q&A)
Topic: PGP/GnuPG Keysigning Party IV
Location:  MIT Building 4-370
Presented by: BLU Volunteers

The purpose of the meeting is to authenticate each other, i.e. verify
everybody's key ids and key fingerprints. Participants sign each others'
keys offline. 

It is essential that, before the meeting, you register on the signup
form listed in the attachments. You should bring at least one picture ID
with you. You must also bring your own printout of the report on that
page, so you can check off the names/keys of the people you have
personally verified.


Please refer to the web site below for further details and to sign up
http://www.blu.org/cgi-bin/calendar/2003-sep

Register at this URL
http://www.blu.org/meetings/2003/09/keypartyregister.php


PLEASE remember to register and print out your report BEFORE the
meeting. We will not have copies for everyone. 

-- 
Jerry Feldman <[EMAIL PROTECTED]>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
___
Isig03 mailing list
[EMAIL PROTECTED]
http://www.blu.org/mailman/listinfo/isig03

--- end forwarded text


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

Re: Is cryptography where security took the wrong branch?

[bmanning]

> 
> At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
> > ok...  does anyone else want to "touch" a secured DNS system
> > that has some parts fo the tree fully signed?  Its a way to
> > get some emperical understanding of how interesting/hard
> > it is to hammer the DNS into a PKI-like thing.
> >
> > www.rs.net  has some information.
> 
> My assertion is 1) DNS integrity issues have to be addressed as part of 
> generalized DNS trust issues  regardless of any use for trusted 
> distribution of information that may include public keys. 2) because domain 
> name infrastructure is the root authority for CA/PKI SSL domain name 
> certificates, there is a suggestion that public keys be registered as part 
> of domain name registration (to fix trust issues in domain infrastructure 
> on behalf of the CA/PKI industry). Being able to trust DNS ... and having 
> registered public keys  means that existing DNS information 
> distribution operation can turn itno trusted distribution of public keys 
> (aka existing DNS infrastructure supports distribution of any information 
> that happens to be registered).

Nice collection of URLs.
Ack both your assertions.  RS.NET is a testbed that is being used to
validate the accuray of those assertions and explore the operational
and social impact with the deployment of a DNS that can respond
with information which can be independently verified for accuracy.


--bill

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

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
ok...  does anyone else want to "touch" a secured DNS system
that has some parts fo the tree fully signed?  Its a way to
get some emperical understanding of how interesting/hard
it is to hammer the DNS into a PKI-like thing.
www.rs.net  has some information.


a normal cache-based system attempts to make everything appear as if it is 
online and dynamic  with the characteristics of information caching as 
close as possibly transparent to the relying-parties.

one might claim that PKIs have tried to turn long-lived certificate-based 
"cache-entries" into a cult (aka from a information theory standpoint, 
certificates are a form of free-standing, somewhat self-describing, stale, 
static, long-lived cache entries)  in part to create an independent 
revenue flow based on these cult objects. standard cache infrastructures 
usually attempt to go out of their way to try and make caching operation 
transparent to relying-parties (and can dynamically change/eliminate 
caching details to meet specific business requirement).

domain name infrastructure needs to support 1) trusted information 
distribution and may implement 2) cached entries. DNS has never been 
restricted to just trusted information distribution of IP-addresses.

CA/PKI SSL domain name certificates were deployed, in part because of 
integrity concerns about the domain name infrastructure. However, the 
"trust root" for CA/PKI SSL domain name certificates is still the domain 
name infrastructure (as to the authoritative owner of a domain name).

Turning DNS into a PKI-like thing happens only in the sense that CA/PKIs 
have only been a trusted distribution of public keys ... while DNS has 
always been a (somewhat) trusted distribution of any information (that 
happens to be registered with them). Adding public keys to DNS distribution 
is only turning it into a PKI-like thing from the standpoint that DNS 
hasn't in the past ben used as a trusted distribution for public key 
specific information (and the issue about the level of trust you can 
actually have in DNS).

My assertion is 1) DNS integrity issues have to be addressed as part of 
generalized DNS trust issues  regardless of any use for trusted 
distribution of information that may include public keys. 2) because domain 
name infrastructure is the root authority for CA/PKI SSL domain name 
certificates, there is a suggestion that public keys be registered as part 
of domain name registration (to fix trust issues in domain infrastructure 
on behalf of the CA/PKI industry). Being able to trust DNS ... and having 
registered public keys  means that existing DNS information 
distribution operation can turn itno trusted distribution of public keys 
(aka existing DNS infrastructure supports distribution of any information 
that happens to be registered).

some past threads about transition steps for DNS trust  which could 
include having cache entries that instead of being naked public keys could 
be digitally signed cache entries (sharing some characteristics in common 
to stale, static, long-lived, free-standing digitally signed certificate 
objects):
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source 
crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source 
crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#17 Payments as an answer to spam 
(addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow 
to broadly catch on (addenda)
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: fyi: bear/enforcer open-source TCPA project

[Sean Smith]

> So this doesn't
> work unless you put a "speed limit" on CPU's, and that's ridiculous.

Go read about the 4758.  CPU speed won't help unless
you can crack 2048-bit RSA, or figure out a way around
the physical security, or find a flaw in the application.


> Yes.  Protocol designers have been explaining how to do them for
> decades.  

But (at a high-level) there are things that are awkward
or extremely impractical to do with, say, multi-party computation.

That's where the "secure hardware" work---from Abyss, to TCPA, to
plastic-speckles, to the CPU+ work at MIT and Princeton---comes in.  



--Sean












-- 
Sean W. Smith, Ph.D. [EMAIL PROTECTED]   
http://www.cs.dartmouth.edu/~sws/   (has ssl link to pgp key)
Department of Computer Science, Dartmouth College, Hanover NH USA




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

Re: fyi: bear/enforcer open-source TCPA project

[bear]

On Tue, 9 Sep 2003, Sean Smith wrote:

>>
>> >How can you verify that a remote computer is the "real thing, doing
>> >the right thing?"
>>
>> You cannot.
>
>Using a high-end secure coprocessor (such as the 4758, but not
>with a flawed application) will raise the threshold for the adversary
>significantly.

The problem with this is Moore's law.  By the time your high-end
coprocessor is widely adopted, most of the actual units out there will
no longer be high-end.  And the kid who has the latest hardware will
always be able to emulate an older secure coprocessor in realtime, the
same way they used to use hacked printer drivers to simulate the
presence of hardware dongles on the parallel port. So this doesn't
work unless you put a "speed limit" on CPU's, and that's ridiculous.

>No, there are no absolutes.  But there are things you can do.

Yes.  Protocol designers have been explaining how to do them for
decades.  There is usually a protocol that allows untrusted machines
to only have data suited for handling by untrusted machines, while
still providing the appropriate benefits.

There are things you can't do that way, of course; a machine cannot
display information to a human that it does not have.  But a
remote-and-therefore-untrusted machine is in front of a
remote-and-therefore-untrusted human, and therefore ought not do such
a thing anyway.

Designing applications that use protocols to achieve design goals
without ever transmitting information that an untrusted machine ought
not have is hard.  But it is possible, and until it's done we're going
to see a parade of cracked applications and hacked hardware destroying
every business plan that's built on it and every life that depends on
it.  Depending on a solution that lets "remote but trusted" hardware
handle information that the remote machine shouldn't have in the first
place is an invitation to be hacked, and an excuse to avoid the hard
work of designing proper protocols.

>> The correct security approach is to never give a remote machine
>> any data that you don't want an untrusted machine to have.
>
>So you never buy anything online, or use a medical facility
>that uses computers?

Online credit-card purchases are ten percent fraudulent by volume.
Crypto is widely deployed for credit-card purchases, but stemming
fraud seems to be like trying to dig a hole in water.  Points made
here recently about who has a motive to stop fraud seem applicable.

And, significantly, much of this fraud is done by people who manage to
crack the merchants' databases of credit card numbers and accounts
which are kept in cleartext.  I don't think any crypto infrastructure
is going to stop "personal" card fraud by someone who's got your card
out of your wallet.  Boyfriends, Girlfriends, roommates, and siblings
commit a lot of fraud on each other.  But a better protocol design
should at least put credit card numbers in merchant databases out of
reach of crackers - by never letting the merchants get them in
cleartext.

A merchant should wind up with a unique "purchase code" - a blob from
which the bank (and no one else) ought to be able to tell the payee,
the amount, the source of funds, and the date of the transaction.
This is fairly simple to do with asymmetric encryption where the bank
has a published key.  A merchant should NOT wind up with a cleartext
credit card number for an online purchase.  Someone hacking the
merchant's database should NOT wind up with information that can be
"replayed" to commit frauds.  This isn't a matter of transmitting
priveleged (sensitive) information to a "remote but trusted" machine;
this is a matter of finding an appropriate (non-sensitive) form of
information that a remote machine can be trusted with.  No special
hardware is required, it's just a matter of using the appropriate
protocol.

Frankly I don't know enough about how medical records are handled to
say much about them - I couldn't even make a good assessment of the
operational requirements.  But the information has huge economic value
as well as huge personal privacy value.  Its inappropriate disclosure
or misuse can destroy lives and livelihoods.  It ought to be
considered, and protected, as a target for theft.

Bear


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

Re: Anyone Remember Zero Knowledge Systems?

[Damian Gerow]

Thus spake R. A. Hettinga ([EMAIL PROTECTED]) [10/09/03 11:51]:
> Imagine a world where your file swapping software also included a
> Freedom-like client that routed your request through a maze of encrypting
> routers. The routers themselves could be placed in different countries.
> This could make for big headaches when the RIAA moves to subpoena logs of
> file swapper's activities. They couldn't get the logs from the ISPs
> because there's no way the ISP could peek in the traffic stream to
> identify offending content. They could try to put a sniffer on a US-based
> encrypting network node, but there's likely little information that could
> be gathered from this; the "payload" of a packet is encrypted with a key
> that the intermediate routers don't know. 

Sounds like Freenet:



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

Re: Is cryptography where security took the wrong branch?

[bmanning]

> 
> At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
> > There are some other problems w/ using the DNS.
> > No revolkation process.
> > DNS caching
> > third-party trust (DNS admins != delegation holder)
> 
> Given high value &/or low trust ... relying parties still have option of 
> directly contacting root authority. And as outline, the root authority is 
> also the root authority for the CA/PKIs. If you attack the root trust 
> authority with false information  then all subsequent trust operations 
> flowing from that false information is suspect. Domain name system still 
> has some exploits against the root database resulting in false information 
>  but since that is the root for both DNS as well as CA/PKIs generating 
> SSL domain name certificates  it is a common failure point for both 
> infrastructures. It needs to be fixed, in order to improve trust on either 
> the DNS side or the CA/PKI side (doesn't matter how thick you make the 
> vault door  if somebody forgot to complete the back wall on the vault).

ok...  does anyone else want to "touch" a secured DNS system
that has some parts fo the tree fully signed?  Its a way to 
get some emperical understanding of how interesting/hard
it is to hammer the DNS into a PKI-like thing.

www.rs.net  has some information.

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


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

Re: Code breakers crack GSM cellphone encryption

[bear]

On Mon, 8 Sep 2003, Dave Emery wrote:

>   Just to amplify this a bit, does anyone seriously think the
>NSA's satellite and embassy based cellphone interception capability is
>primarily targeted against - US - GSM calls ?   Or that they can
>routinely get warrants to listen in using the wired tapping
>infrastructure in say Russia or France or Iran ?

Of course the NSA's satellite and embassy based cellphone interception
capability isn't primarily targeted against - US - calls; that would
be illegal.  The snooping in the US is done by others and then handed
over to the NSA instead.  And of course the NSA does the same for
them.  This is what the UKUSA agreement is all about.

Bluntly, no matter who does the actual interception work, in the
modern world every intel agency's analytic and correlative resources
are targeted against everybody in the world.  To say that some
particular agency doesn't do intercepts in some particular country is
irrelevant; It's all just data. Remember lawmakers learning that the
internet treats censorship as damage and routes around it?  Well,
we're looking at the same phenomenon here: the worldwide intel
community treats privacy laws and operational restrictions as damage
and routes around them.  It's exactly the same thing.

I'd be willing to bet most nations even get intel on their own
citizens that's gathered by actively hostile countries: An actively
hostile nation, let's say, snoops on american citizens.  Then they
share the intel product with someone they've got a treaty with, and
then that country shares it with somebody they've got a treaty with,
and they share it with the US.  It's all just routing.  Someone has
information somebody else wants, somebody else has money or intel to
swap for it.  It doesn't take a genius to figure out, it's just going
to happen.  Anything an intel service shares with anybody, it's
putting into the network, and it's going to get around to everybody.

Bear

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

Anyone Remember Zero Knowledge Systems?

[R. A. Hettinga]

Cryptonomicon.Net - 

Anyone Remember Zero Knowledge Systems? 
Date: Wednesday, September 10 @ 11:15:00 EDT 
Topic: Commercial Operations / Services 


It seems that a day doesn't go by that there's new news about the RIAA suing another 
file swapper. First it's college students, then it's 12-year old honor students, and 
we hear that they're going after senior citizens next. With ISPs either volunteering 
or being forced to divulge subscriber information, it's a wonder that there isn't a 
technology to help shield user's online privacy with respect to their file swapping 
activities. 

Well... actually there is, and it's been around for a couple of years. 



We don't normally do commercial endorsements here, but when we see so much chatter 
from people on newsgroups talking about privacy protecting technology, we figured we 
should probably chime in. Way back in the late 90's a company called Zero Knowledge 
Systems was formed to develop privacy enhancing technology for the Internet. Their 
flagship product Freedom.Net was a giant onion-skin routing cloud with encrypted 
links. The idea was that someone desiring privacy would open an encrypted link with a 
Freedom.Net node and send it's internet requests through that node. That node in turn 
would encrypt the request and route it through another semi-randomly selected node 
using a different encryption key. This process would repeat until the request exited 
the cloud of encrypted packet routers and hits the target of it's destination. The 
response to the request would return via a similar convoluted, encrypted path. 

At the time, Freedom.Net was being pitched as a tool for human rights workers, 
whistleblowers, or even parents who don't want identifying information about their 
children being collected by heartless corporations intent on selling their kids the 
latest Anime action figures. 

Unfortunately, they never quite made a compelling enough argument for mass adoption of 
their system and eventually morphed the company into a manufacturer or more 
conventional privacy tools. Freedom still exists as a product, thought it is aimed at 
web users, only runs on Windows clients, and routes requests through proxy servers 
owned by Zero Knowledge Systems. 

It is interesting to ponder what would happen if the Freedom network were widely 
deployed and routing file swapping packets. One key feature of the original Freedom 
network was that routing nodes could (and would) be placed in different legal 
jurisdictions. Assuming that node operators actually logged packet traffic, 
organizations like the RIAA would be forced to subpoena node operators in multiple 
countries; a process humorously referred to as "Jurisdictional Arbitrage." 

Imagine a world where your file swapping software also included a Freedom-like client 
that routed your request through a maze of encrypting routers. The routers themselves 
could be placed in different countries. This could make for big headaches when the 
RIAA moves to subpoena logs of file swapper's activities. They couldn't get the logs 
from the ISPs because there's no way the ISP could peek in the traffic stream to 
identify offending content. They could try to put a sniffer on a US-based encrypting 
network node, but there's likely little information that could be gathered from this; 
the "payload" of a packet is encrypted with a key that the intermediate routers don't 
know. 

About the only place the RIAA could attack would be the servers. After all, all the 
encryption in the world won't help you if you publicize the IP address of your file 
store. I'm sure what keeps the record industry executives up at night is the worry 
that somewhere in the middle of the backwoods of Colombia or in the occupied 
territories of Israel / Palestine there are extra-territorial jurisdictions that can't 
be served with papers. Honestly, do you really want to be the process server that goes 
in to serve papers on FARC guerillas? 

The future is unclear, but while we start thinking about critical infrastructure, 
maybe we could think about a way to protect the record companies from financial ruin 
at the hands of FARC or HAMAS. Yes, I know there are several out there who would like 
to help destroy the RIAA and all they stand for. Yes, they are behaving in a manner 
indistinguishable from bastards. But they're our bastards, and if they are to be 
"taken down," there's a legal process for doing so. 

It's well known that Hollywood has much better political representation than Silicon 
Valley. What would happen if KaZaa or Gnutella or Sharmin Networks started operating 
an encrypted network? Would the RIAA move to outlaw encryption? Maybe the 
entertainment companies would buy the ISPs and block encrypted content from traversing 
their network. In any event, we see a whole new chapter in the privacy wars brewing. 
Don't say you weren't warned. 






This article co

Bear: An Open-Source Virtual Secure Coprocessor based on TCPA

[R. A. Hettinga]

Papers 
www.cs.dartmouth.edu/~sws/abstracts/msmw03.shtml 
Last modified: 08/27/03 11:56:52 AM 

Rich MacDonald, Sean W. Smith, John Marchesini,  Omen Wild. 
Bear: An Open-Source Virtual Secure Coprocessor based on TCPA 
Technical Report TR2003-471, Department of Computer Science, Dartmouth College. 
August 2003. 

Abstract 
This paper reports on our ongoing project to use TCPA to transform a desktop Linux 
machine into a virtual secure coprocessor: more powerful but less secure than 
higher-end devices.  We use TCPA hardware and modified boot loaders to protect fairly 
static components, such as a trusted kernel; we use an enforcer module---configured as 
Linux Security Module---to protected more dynamic system components; we use an 
encrypted loopback filesystem to protect highly dynamic components. 

All our code is open source and available under GPL from 
http://enforcer.sourceforge.net/ 

Download 
PDF 

Code 

Back to home page 
Maintained by Sean Smith ,[EMAIL PROTECTED] 

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

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 08:14 AM 9/10/2003 -0600, Anne & Lynn Wheeler wrote:
entry. We ran into a problem with doing consistent database updates over 
NFS (network filesystem) because while NFS advertises itself as item 
potent, most client implementations have this 8k cache that can be stale.
fingers typing w/o brain syncronized ... it should have been idempotent not 
item potent.
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote:
There are some other problems w/ using the DNS.
No revolkation process.
DNS caching
third-party trust (DNS admins != delegation holder)
Since DNS is a online positive list  you change the database ... and 
voila it is updated.

This is the scenario for credit cards going from pre-70s technology with 
plastic cards and the monthly revokation booklet mailed out to all 
merchants. The credit card industry transitioned to online infrastructure 
where it transactions are denied by updating the online database. It 
eliminates the revokation process, since there aren't an unknown number of 
copies of static, stale credentials/certificates floating around the world 
potentially being presented to an unknown variety of relying parties.

DNS caching is the closest equivalent of the certificate paradigm of 
static, stale copies floating around the world. The two slight differences 
are that cached stale, static entries tend to have very short lifetimes ... 
they come into creation by activities by the relying-party (not the entity 
being authenticated) and tend to have very short lifetimes  of a few 
hours to at most a day. However, relying-parties have the choice of going 
directly to the root and obtaining the current copy  a function 
somewhat filled in the PKI world by OCSP  although OCSP is just a check 
about whether the current, static, stale copy in a relying-party's 
possession is current ... not what the current entry is..

From information theory standpoint, stale, static certificates are 
logically a form of long-lived, distributed, replicated, r/o, cache 
entries.  Cache entry semantics have been studied in some detail in areas 
like distributed file systems and multiprocessor consistent shared memory 
caches, etc.  With short-lived r/o, distributed cache entires (like DNS) 
... there is a trade-off involving 1) entry life-time, 2) frequency of 
change, 3) impact of dealing with stale entry. We ran into a problem with 
doing consistent database updates over NFS (network filesystem) because 
while NFS advertises itself as item potent, most client implementations 
have this 8k cache that can be stale.

Given high value &/or low trust ... relying parties still have option of 
directly contacting root authority. And as outline, the root authority is 
also the root authority for the CA/PKIs. If you attack the root trust 
authority with false information  then all subsequent trust operations 
flowing from that false information is suspect. Domain name system still 
has some exploits against the root database resulting in false information 
 but since that is the root for both DNS as well as CA/PKIs generating 
SSL domain name certificates  it is a common failure point for both 
infrastructures. It needs to be fixed, in order to improve trust on either 
the DNS side or the CA/PKI side (doesn't matter how thick you make the 
vault door  if somebody forgot to complete the back wall on the vault).

random, unrelated refs to past life working on processor cache design, 
distributed filesystems, and distributed databases
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Is cryptography where security took the wrong branch?

[bmanning]

> >certificate requests coming into a CA/PKI can be digitally signed, the 
> >CA/PKI can retrieve the authoritative authentication public key (for the 
> >domain name ownership) from the domain name infrastructure and 
> >authenticate the request  eliminating all the identification gorp (and 
> >also done w/o the use of certificates).
> >
> >misc. additional recent musings:
> >http://www.garlic.com/~lynn/2003l.html#60  Proposal for a new PKI model 
> >(At least I hope it's new)

Not particularly new. This was/is the promise of DNSSEC.
early work, the TBDS and FMESHD projects.  Current IETF
work, OE and IPSECKEY.

> The problem is that the domain name infrastructure has a database of domain 
> name owners  but no real good infrastructure ... 

Not entirely.  The reverse maps are a well defined infrastructure
space.

> Of course, the bottom line is if the domain name infrastructure has a 
> real-time database of public keys for authentication purposes  in part 
> for use by the CA/PKI industry for authenticating SSL domain name 
> certificate requests  for use in authentication operations  the use 
> of the domain name infrastructure's authentication public keys don't have 
> to just be restricted to authentication use by the CA/PKI industry. In 
> fact, domain name infrastructure authentication public keys could be used 
> to effectively for authentication operations that actually subsume the SSL 
> domain name certificates authentication operations.

There are some other problems w/ using the DNS.
No revolkation process.
DNS caching
third-party trust (DNS admins != delegation holder)

> 
> --
> Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
> Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
>   
> 
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
> 


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