Subject: Re: [Asrg] New take on emerging idea. (Query/C-R system?)

From: "John Fenley" <[email-masked]>
Date: Fri, 11 Apr 2003 19:23:22 -0600

>From: Kee Hinckley <[email-masked]>
>And none of this has anything to do with your proposal, which is completely 
>unrealistic in all of its aspects--and does nothing to curb spam any more 
>than a personal whitelist.

you are wrong.

What I propose is a system in which a Whitelist, a Challenge/Response 
system, and mailing lists and other automated systems can work together. All 
the advantages, none of the disadvantages.
John Fenley

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "John Fenley" <[email-masked]>
Date: Fri, 11 Apr 2003 20:15:01 -0600

>From: J C Lawrence <[email-masked]>
>John Fenley <[email-masked]> wrote:
>
> > But enough about that... Does anyone have a reason that my system
> > could not be used as a loose framework?
>
>Quite a few actually, but that gets into questions of information
>theory, protocol design, zero knowledge systems, etc that I'd much
>rather point you at generally than spend my time explaining what so many
>others have done so well.

ok...
After some reaserch...
Information theory: How to make sure your message gets to it's destination 
unchanged... The internet allows this regularly.

Protocol design: What about how the whois database worked? I can't find much 
data on it, but it worked for a long time as a single database.

zero knowledge systems: I don't see how that applies to a public database.

> > Forget my bias against spam boxes. Assume it can be funded. Assume it
> > could be distributed in nature (cashes or something).
>
>Those are neither cheap or easy assumptions.  They are also rather
>critical assumptions.  Getting buy-in is not just fundamental, but is a
>prerequisite for any proposal to be considered seriously.
>
>Adding distribution to a protocol system is not just a matter of
>sprinkling magic "distribute-this" pixie dust.  Its hard work, and
>frequently impossible without gutting the starting premises.

Pixie dust: Anybody can sign up to recieve dialy updates to the database, 
and lists of valid entrys should be available. creating a private mirror 
would save a company bandwidth.

John Fenley

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 12 Apr 2003 05:07:10 -0700

> "John Fenley" <[email-masked]> wrote:
> > The real question was who pays for this system.
> > I propsed the US government because they are an oganization 
> who's purpose is 
> > to supply needed systems to the population, that would be 
> to costly for a 
> > buisines.
> > Would we have an interstate highway system, or hoover/glen 
> canyon/Grand 
> > Coulee Dam without the government? These systems help everyone.
> 
>   Not me.  I don't live in the U.S., and I have no plans to *ever*
> live in the U.S.
> 
>   As Chuq noted, the U.S. is not the entire world.  Not everyone
> trusts the American government.  Any system *must* work world-wide,
> and MUST NOT depend on the benevolence of one government.

Actually when it comes to it the US government does not really want
to perform this role.

As a point of fact projects at least as expensive in terms of capital
as the Hoover dam are constructed using private capital. Of course
no project of that type could be achieved in a state of complete 
anarchy, but the fact that anarchy and central planning are not the
same thing does not mean there are the only alternatives. There is 
a whole spectrum in between, from the corporate kleptocracy to 
socialism.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 12 Apr 2003 09:41:35 -0700

> Without authenticators such as shared secrets or public keys, it is
> obvious that SSL or TLS does nothing against a classic 
> man-in-the-middle
> attack.  

If you read the damn spec you will realise that it is obvious that
it supports that use. I fact I don't believe SSL supports any other
use whatsoever.

So your statement being vulnerable against a man in the middle 
attack would be pure unadulterated B/S. 

As is the rest of your message.

Go read Bruce Schnier's Secrets and Lies. It took a long time before
he understood that security was a matter of risk control rather than
risk elimination.

		Phill

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 12 Apr 2003 14:49:33 -0600 (MDT)

> From: "Hallam-Baker, Phillip" <[email-masked]>

> > man-in-the-middle attack.  
>

I don't understand which is the use that "it is obvious that it supports
that use."  I hope that is not a claim that SSL/TLS can only be used
with PKI or other authentication systesm.  SMTP-TLS and HTTPS (HTTP/TLS)
are frequently used in supported modes do not provide much authentication.
Reading the standards can be useful, particularly for those without
direct experience implementing, installing, or maintaining installations
of the protocols.  (That evidently includes many of us here and for
more than just TLS, HTTPS, and SMTP-TLS).   See for example page 4 of
RFC 2246 which says:

    - The peer's identity can be authenticated using asymmetric, or
      public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
      authentication can be made optional, but is generally required
      for at least one of the peers.

Without shared secrets or public keys to provide authentication,
SSL/TSL does not and cannot provide authentication.  A man-in-the-middle
attack when there are no shared keys is as easy as inserting a system
into the path between the victims.  That can be done with DNS spoofing
or various routing games including ARP tricks.

Consider the case of using TLS to connect to port 25, 80, or 587 on
www.rhyolite.com.  Unless your SMTP or HTTP client has a trustworthy
copy of the self-signed certificate for www.rhyolite.com, you client
cannot know that it is talking directly to my SMTP or HTTP server.
A bad guy could have tricked your client into thinking that the IP
address for www.rhyolite.com is his IP address.  When your client
connects to what it thinks is my system, it would really be talking to
the bad guy's system.  The bad guy's system can make a second connection
to my system, and pass whatever your systems sends to mine and vice
versa.  The bad guy can see all of our bits and modify them.
(I realize that I'm repeating this for the third time in the last 24
hours.  That I've apparently not been clear to one person suggests
that I've not been clear to other people.)

If your client has a copy of the self-signed certificate for
www.rhyolite.com, you need to ask whether it is trustworthy.  A bad
guy could have intercepted your HTTP or FTP connection to 192.188.61.3
when you fetched that certificate and replied with his version of my
certificate.  (Anyone who really needs my certificates or other
keys contacts me out of band.)

> he understood that security was a matter of risk control rather than

Bruce Schnier has been repeating that and other good observations for
years.  I don't think he or anyone who has thought about security
needed to be told that obvious fact or other obvious facts such as
the importance of looking at the system instead of only the algorithms
or at the whole path instead of only the middle.  On the other hand,
many who swallowed security snake oil have been flabbergasted by the
observations in "Secrets and Lies."

Apply that observation to HTTPS or SMTP-TLS to 192.188.61.3, the
likelihood of a man in the middle for anyone using TLS to 192.188.61.3
is very low.  It's just not worth the effort to insert a man in the
middle between my systems and strangers'.  Also low but not quite as
low is the possibility of someone or some agency snooping on our packets.
Snooping in this case without an man in the middle is not practical,
despite any lack of shared, trustworthy certs.

Another application of Bruce Schnier's observations is that men in
the middle can be inserted in many places.  Someone who has obtained
a trustworthy copy of the right authenticators, such as by courier
or commercial PKI is still vulnerable to a man in the middle.  It's
easy to install software on a Windows box that will modify keyboard
"messages" (not network but WIN32 API things) and other data and
so redirect the victim, or just capture keystrokes.  The bad guy
would be in the middle of the path between the user's fingers and
eyes and any other system, albeit not in the middle of the middle.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg