Re: Failure of PKI in messaging

2007-02-16 Thread James A. Donald

--
  My proposal closes off the major attack path

John Levine wrote:
 It doesn't do anything about the obvious attack path
 of phishing credentials from the users to stick bogus
 trusted entries into their accounts.

Actually it does.  Think about it.

 My examples showed all sorts of benign looking
 situations in which users provide their credentials to
 parties of unknown identity or reliability.

I don't see that your examples have any relevance to my
proposals.  The word credential is nowhere mentioned
or relevant,  nor is providing one's credentials to
criminals a problem unless one's crediential is in fact
a shared secret, such as a credit card number.  So we
should not use shared secrets any more - that is a given
for any and all serious proposals.

Your criticism is not a criticism of my proposal, it is
a criticism of using the same password all over the net.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 hyNNu45kHRCn/6vEXQhYdbU/w1YW4J/TF8BDsJz0
 495s+VYSd3RjDiopACgr9JccOdvE7cTtQV6xgA8sK

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


Re: Failure of PKI in messaging

2007-02-16 Thread silvio
Leichter, Jerry wrote:

 I think the whole notion of decentralizing *everything* has turned out
 to be a trap.  Yes, it makes for great cryptography and system design to
 find ways to do without a trusted third party.  But the resulting
 systems just don't fit the way people think and work.  Trust has
 *always* been based on personal contact

In human interactions trust is not based upon a centralized authority
either. So having a decentralized, inter-human solution such as PKI is
actually a lot closer to the natural ways of things, than the SSL
CA-based infrastructure.

The human touch is somewhat missing though and that's an implementation
issue. For example, one of the heavily underused features of GPG is the
picture ID. It'd make a lot more sense for non-geeks to see a picture of
their friend message verified to come from [pic here] than the more
obscure Good signature from John Doe which needs to be interpreted.
Likewise the mentioned use of colors, which would aid in intuitive
understanding of the authenticity and security of a message (or lack
thereof).

Silvio

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


Re: Failure of PKI in messaging

2007-02-16 Thread Anne Lynn Wheeler

John Levine wrote:

It doesn't do anything about the obvious attack path of phishing
credentials from the users to stick bogus trusted entries into their
accounts.  My examples showed all sorts of benign looking situations
in which users provide their credentials to parties of unknown
identity or reliability.


part of x9.59 financial standard
http://www.garlic.com/~lynn/x959.html
http://www.garlic.com/~lynn/subpubkey.html#x959

was to consistently require (digital signature) strong authentication and integrity on all transactions. as a result, phishing, data breaches, security breaches (with regard to account numbers) was eliminated as risk vector (account numbers could be divulged, phished, breached, etc ... but couldn't be used for fraudulent purposes). this also eliminated needing SSL for electronic commerce transactions (as part of hiding account numbers). in the online model ... don't require independent stand-alone/offline paradigm credentials ... just need a reliable authentication mechanism that is reasonably resisted to attacks. 

sort of as part the x9.59 effort ... in the later half of the 90s, was the aads chip strawman 
http://www.garlic.com/~lynn/x959.html#aads


as countermeasure to software private keys being easily compromised ... i.e. digital signature becomes a something you have authentication operation ... i.e. it represents having unique hardware token containing the private key that generates the digital signature. 


the next issue was hardware token costs ... both the costs of individual 
hardware tokens ... as well as the aggregate infrastructure costs related to 
institutional centric model with each institution issuing their own hardware 
token.

the first part was addressed by eliminating everything thing from the chip that wasn't in direct support of (security) 
of something you have authentication ... and the other was moving from a institution centric 
hardware token to a person centric hardware token. Moving to a person centric hardware token 
also turns out to eliminate a bunch of institutional hardware token personalization costs.  The objective was 
aggressive cost reduction gaining possibly two orders of magnitude on per chip  and instead of requiring a unique 
hardware token effectively replacing every password a person currently uses ... just have one (or a small few) tokens 
per person. Institutional specific credentials go away ... since the increase the per chip issuing costs and  tend to 
eliminate person-centric operation (resulting in unique chips per institution).

This makes the hardware token (something you have) authentication much more analogous 
to biometrics (something you are) authentication. The hardware token for digital 
signature ... is presented in very much the same way a RFID chip (with static number vulnerable to 
replay attacks) might be presented ... or a fingerprint is sensed (again w/o being subject to 
replay attacks)  but not requiring any other infrastructure, institutional, or application 
specific processing (it becomes a single function ... authentication, unlimited multi-app ... for 
whatever apps require authentication ... implementation).

A couple of the remaining vulnerabilities are

1) social engineering attacks getting victim to directly perform operations on 
behalf of
the attacker.
2) direct chip attacks to give up private key

current phishing tends to be convincing the person that they have to divulge some piece of 
information to verify and/or in support of other operations. the attacker then uses the information 
to perform fraudulent transactions w/o the victims knowledge. social engineering to perform 
operations on behalf of the attacker would tend to raise alarms in more peoples minds and possibly 
has less fraud ROI ... since it would presumably require more effort on the attacker's behalf for 
each fraudulent transactions. another possible social engineering operation is to convince the 
individual to return their hardware token (possibly as part of some required exchange 
operations). This would be easier done with the institutional-centric model ... since the victims 
would associate the token with the institution ... rather than believing they owned the 
token (in a person-centric model).

the issue in direct chip attacks is attempting to keep the cost of the attack somewhat higher than reasonable expected returns for the attacker ... i.e. part of this is parameterized risk management. the other is try and have the various chip attacks reasonably take longer than the typical lost/stolen reporting interval ... i.e. associated with an online transaction model. 
If the chip attacks cost more than the reasonable return to the attacker ... or the attack typically takes longer than avg. remaining lifetime before a lost/stolen report deactivates the chip.
In the parameterized risk management scenario ... the risk profile is registered for each kind of chip ... while there is possibility of a single kind of chip 

Re: BETA solution, Re: Failure of PKI in messaging

2007-02-16 Thread Ed Gerck
Guus Sliepen wrote:
 On Thu, Feb 15, 2007 at 02:47:05PM -0800, Ed Gerck wrote:
 
 Zmail actually reduces the amount of trust by not storing your usercode,
 password, or keys anywhere. This makes sense for zmail, and is an incentive
 to actually do it, to reduce risk -- anyone breaking into any zmail server,
 even physically, will not find any key or credential material for any user
 and, hence, cannot decrypt any user area (the user area keeps the address 
 book
 and contact keys, all encrypted using the user keys that are not there), or
 user messages collected from ISPs.
 
 Where are the usercode, password and keys stored then?

N O W H E R E, as it says above.

 [...]
 This will actually be available in v3.x, with an option for client-based
 super-encryption. If you are concerned about zmail peeking into the raw
 message, which zmail does not do, you can simply agree with your message
 partner on an out-of-band passphrase and use it in your client (without
 zmail access) to encrypt. Your recipient can do the same to decrypt. What
 you get from zmail is the secure routing and distribution -- for example,
 you can require the recipient to login, allow the recipient to prevent
 phishing, and expire the message in 7 days. You can also request a return
 receipt telling you when, where, how, and by whom the message was decrypted.
 
 /If/ I trust ZMail (the people behind it and the X.509 stuff that
 secures the website) then yes, this is functionality not offered by SMTP
 and PGP or S/MIME. But I don't see this replacing PGP or S/MIME. 

There's no need to replace PGP or S/MIME. After all, less than 5% of all email
is encrypted using them. What's needed is to offer an option for the other
95% that could be encrypted and authenticated.

I also
 still don't see how this improves the trust model.

Because you have to trust zmail less (the two quotes above), and also because
you have to trust the recipient less (the return receipt, for example). In
addition, you have to trust your platform less (no private-key that is stored
in your computer; ZSentryID can be used to render key-logging ineffective).
In short, the less you have trust everyone (including your own computer),
the better the trust model is -- what you trust is what can break your
security, when it fails.

Best,
Ed Gerck

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


Re: Failure of PKI in messaging

2007-02-15 Thread Ed Gerck
John Levine wrote:
  The great thing about Internet e-mail is that
 vast numbers of different mail systems that do not know or trust each
 other can communicate without prearrangement.  

That's not banking. Banks and their clients already have a trusted
relationship. The banks webmail interface leverages this to provide
a trust reference that the user can easily verify (yes, this is my
name and balance). That's why it works, and that's what is missing
in the bank PKI email model -- what's that relationship buying you?

Email for banks should thus leverage the relationship, rather than
present an ab initio communication.

 It's hard to see any
 successful e-mail system in the future, secure or otherwise, that
 doesn't do that, since Internet mail killed all of the closed systems
 that preceded it.

It is not true that you can't secure first communications. It is just
harder and _not_ necessary for banks (because the client already knows
the bank and vice versa).

Best,
Ed Gerck

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


Re: Failure of PKI in messaging

2007-02-15 Thread Leichter, Jerry
On Tue, 13 Feb 2007, Anne  Lynn Wheeler wrote:
| ...part of the problem was that the PKI financial model is out of
| kilter with standard business practices. nominally a relying party has
| some sort of relationship with the certification authority (i.e. what
| they are relying on) and there is exchange of value between the two
| parties.
| 
| In the standard PKI model, there frequently is absolutely no
| relationship between the relying party and the certifying agency. The
| owner of the digital certificate is paying the certifying agency
| ... not the relying party ... so there is typically no exchange of
| value between the certifying agency and the relying party ... and
| therefor the relying party has no foundation for actually relying on
| the certifying agency
This is an excellent point - completely obvious once made (and I know
you've made it before, but for whatever reason, the inverted relation-
ship between certifier and signer/relying party never quite sank in
for me).

It's interesting to follow up on this idea, because it shows just how
profound the problem is.  Imagine starting a business that ran a PKI
and did business the old way:  You would charge someone *presenting*
an alleged certificate for an OK.  The OK would, for the fee paid,
provide insurance against the possibility of fraud.  (Presumably, the
fee would be based on the size of the insured transaction and level
of experience and trust you have in the signing party.)  It's to
your advantage to have many parties whose signatures you vouch for,
since that's what brings you customers; so you probably don't charge
that side of the business - though it helps someone to have a high
trust signature, since their customers will like paying a lower
premium to do assured business with them, so you could charge on
that side in some cases.  But, unlike the case today, since your
own money is at stake if you vouch for someone untrustworthy, you
can't just go hand certs out to anyone who shows up at your door.

In the business-to-business case, things have worked like this (more
or less) for years.  This is pretty much what Dun and Bradstreet do,
for example (though they don't do the actual insurance part - they
rely on their own reputation to provide as much assurance as is needed
for typical transactions).  But can we even imagine a situation in
which Internet shoppers were willing to *pay* - even a nominal amount
- for assurance that the Amazon page they hit really was Amazon's?
There are at least two levels of established practice in the way:

- Assurance services at the consumer level barely exist in
the real world.  We rely mainly on various surface
indicia - appearance, responsiveness, apparent age
and stability, trademarks - that are reasonably good
in the real world but basically useless on the Net
We also rely on reputation, which we almost always
hear about for free.

- Information on the Internet is expected to be free.  There
are relatively few exceptions that have gained any
traction, and they tend to be for bigger pieces of
information.

This analysis indicates yet again why this is, and will likely remain,
an intractable problem.
-- Jerry

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


Re: Failure of PKI in messaging

2007-02-15 Thread Anne Lynn Wheeler

Leichter, Jerry wrote:

It's interesting to follow up on this idea, because it shows just how
profound the problem is.  Imagine starting a business that ran a PKI
and did business the old way:  You would charge someone *presenting*
an alleged certificate for an OK.  The OK would, for the fee paid,
provide insurance against the possibility of fraud.  (Presumably, the
fee would be based on the size of the insured transaction and level
of experience and trust you have in the signing party.)  It's to
your advantage to have many parties whose signatures you vouch for,
since that's what brings you customers; so you probably don't charge
that side of the business - though it helps someone to have a high
trust signature, since their customers will like paying a lower
premium to do assured business with them, so you could charge on
that side in some cases.  But, unlike the case today, since your
own money is at stake if you vouch for someone untrustworthy, you
can't just go hand certs out to anyone who shows up at your door.


re:
http://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in message
http://www.garlic.com/~lynn/aadsm26.htm#33 Failure of PKI in messaging ... 
addenda

note that merchant interchange fee works this way ... i.e. the merchant
wanting to know whether it gets paid when you present your card

recent posts with some interchange fee references
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high 
priority for 2007
http://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a 
high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a 
high priority for 2007

doing the original deployment of what currently has come to be called 
electronic commerce,
there was some investigation whether the payment infrastructure would issue 
certificates
... since they were already certifying merchants for processing of payment 
transactions
(and the digital certificates then become representation of that certification).
As mentioned before, merchants were already paying fairly hefting interchange 
fee
to effectively insure consumer transactions ... that would have somewhat 
boxed-in/capped
fees for ssl domain name certificate operations ... which weren't providing 
anything
... other than a lot of publicity and hype convincing public that they should 
feel
good about digital certificates ... previously referenced posting in this blog
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the 
minimum liability, the CA trap, the market in browser governance

as i've often mentioned before ... this is probabily why the fed gov. PKI has GSA signing 
contracts with certification authorities ... effectively them making them agents of the

federal gov. ... so there is avenue for recourse and business reliance between 
the
federal gov as the relying party and the fedreal gov as the certificate issuing 
operations
(thru their agents via contractual relationship) ... i.e. effectively a relying party 
PKI operations

http://www.garlic.com/~lynn/subpubkey.html#rpo

the argument then is that in an online environment, the relying-party digital 
certificates
are redundant and superfluous. The two diminishing market segments are 


1) the original design point for digital certificates, situation where the 
relying party has no repository of their own regarding prior relationship with 
the certified entity and/or have no timely connectivity to a certifying agency

2) no-value operations where the value of the transaction can't justify relying 
parties keeping their own records and/or doing a real-time transactions.

both of these remaining PKI market segments are rapidly shrinking as internet 
online connectivity becomes ubiquitous and as the costs of dataprocessing and 
networking continues to drop.

as mentioned numerous times, in effect, x9.59 financial standard just augmented 
existing payment transactions with digital signature for authentication and 
integrity.  there were no requirement for digital certificates ... for a wide 
variety of reasons ... in addition to being redundant and superfluous ... the 
digital certificates represented an enormous payload and processing bloat that 
providing no fundamental added value
http://www.garlic.com/~lynn/subpubkey.html#bloat

the x9.59 consistent application of digital signature for authentication and 
integrity ... w/o requiring any certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

also eliminated simply knowing the associated account number as a 
vulnerability ... that then eliminates a lot of the risk currently associated with 
phishing and data breaches. x9.59 didn't eliminate phishing and data breaches  it 
just eliminated attackers being able to utilize a lot of the acquired information for 
fraudulent purposes.

With a pervasive use of SSL in the world 

Re: Failure of PKI in messaging

2007-02-15 Thread Florian Weimer
* James A. Donald:

 Obviously financial institutions should sign their
 messages to their customers, to prevent phishing.  The
 only such signatures I have ever seen use gpg and come
 from niche players.

Deutsche Postbank uses S/MIME, and they are anything but a niche
player.  It doesn't help against phishing in the sense that deters the
attackers and reduces the PR impact.

 I have heard that the reason no one signs using PKI is
 that lots of email clients throw up panic dialogs when
 they get such a message, and at best they present an
 opaque, incomprehensible, and useless interface.  Has
 anyone done marketing studies to see why banks and
 massively phished organizations do not sign their
 messages to their customers?

Why bother, when it's been shown it doesn't make a difference?

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


Re: Failure of PKI in messaging

2007-02-15 Thread James A. Donald

Ivan Krstić wrote:
 This is, in my experience, exactly right. I'm trying
 to take some steps for the better on the OLPC: all
 e-mails and IMs will be signed transparently and by
 default, with the possibility of being encrypted by
 default in countries where it's not a problem. This'll
 help with privacy and message integrity, but it's not
 designed to stop phishing or impersonation.

Matt Blaze has proposed despair - that message
authentication cannot defeat phishing,  Ivan Krstić has
proposed a system not intended to address phishing.

Naturally I have a solution - the only problem is to get
from where we are to there.  I was interested in the
banks perception that PKI was not working - what led
them to realize that PKI was not working or led them to
doubt that PKI would work, for in order to get from here
to their, have to persuade them that my solution *will*
work.  I was hoping for a response from the usual
defenders of PKI, who would, I hoped, give me the inside
scoop on the problems that Verisign has encountered with
its customers.

The solution to phishing:

Suppose we have a messaging service that, like Yahoo, is
also a single signon service, and, like OTR or Skype
voice messaging, delivers authenticated encrypted
messages.  Better, multiple such message services that
interoperate.

Suppose that when you register at a website for single
signon onto that website you get an icon in your
messaging client similar to a buddy icon, but
corresponding to that website instead of a buddy.
Zooko's rules apply - default name is title of logon
page that the user will see when logged in, but name is
local, user can modify it.  User has to handle name
collisions locally.  Click on the icon in your messaging
client, your browser is launched and logged on at the
web site, and that is the *only* way you can logon onto
that website in your single signon identity.   We want
the name of icon to default to same title as the logged
in page, for consistency with the experience of using
favorites -

The user experience should resemble using buddy icons
and also resemble using favorites icons.  When you click
on a registered website icon, instead of getting a text
box to type in a message, you instead get a browser page
logged in to the website.

If the web site is on the user's list for single signon,
then by default the website is enabled to send him
messages.  Only his buddies and enabled websites can
send him messages, and they can only be enabled if he
has an icon in his messaging system that represents
single click login.

The website sends message title and a url argument. User
sees a button, and the text message title from
user's name for website.   If he clicks on that
button, he gets logged in as usual, but instead of
seeing his usual web page, sees a web page with that
title, that web page containing the actual message body.
Thus the user typically sees in his messaging client an
email like list of messages each with a button/link that
says:
title of target web page from title of usual
login page

These messages are given less immediacy than messages
from buddies - they are just put in a list like email,
for there is no live human waiting at the other end. The
single signon icons work like both buddy and favorites
icons, but the message icons work like email icons, not
like popups from actual buddies.

I have described the user experience, not the underlying
crypto, for everyone on this list can see how to use
crypto to give effect to the behavior described and
prevent adversaries from spoofing that behavior, but had
best post up the underlying crypto shortly, lest some
troll patent it.   The underlying crypto is, of course,
similar to that used by Skype and OTR, plus for the
login phase similar to the petname tool and OpenID.

It is not at all clear, however, how to make this
interoperate with Jabber/XMPP, for last time I checked
Jabber had no capabilities discovery mechanism, and in
consequence all the various officially approved jabber
encryption protocols were useless for any sane purpose.
On the other hand, the core of OpenID is nothing but a
capabilities discovery system, so perhaps some
combination of Jabber with OpenID could work.  I have
not thought the issue of Jabber compatibility through.
I participated briefly on that standards list, and
came to the conclusion that they could not run a
lemonade stand, much less produce a useful standard.

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


Re: Failure of PKI in messaging

2007-02-15 Thread James A. Donald

Ed Gerck wrote:

I am using this insight in a secure email solution that provides
just that -- a reference point that the user trusts, both sending
and receiving email. Without such reference point, the user can
easily fall prey to con games. Trust begins as self-trust. Anyone
interested in trying it out, please send me a personal email with
application info.


Want to try it out.  Not clear what you mean by application info.

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


Re: Failure of PKI in messaging

2007-02-15 Thread Leichter, Jerry
| Banks [use] a web interface, after the user logs in to their account.
| 
| So, what's missing in the email PKI model is two-sidedness.
| Fairness.
| 
| Not really.  What's missing is, if you'll pardon the phrase, a central
| point of failure.
| 
| If you can persuade everyone to use a single system, it's not hard to
| make communication adequately secure.  Look at Hushmail; if you
| believe that their internal processes are OK, you can set up an
| account and communicate quite securely with other Hushmail users on
| their web site, or for the more nerdy, you can use SSL IMAP and PGP to
| communicate with their central site.  It's been limping along since
| 1999, I don't know anyone who uses it which says something about its
| actual utility.
| 
| But that's not e-mail.  The great thing about Internet e-mail is that
| vast numbers of different mail systems that do not know or trust each
| other can communicate without prearrangement.  And of couse the awful
| thing about Internet e-mail is the same thing.  It's hard to see any
| successful e-mail system in the future, secure or otherwise, that
| doesn't do that, since Internet mail killed all of the closed systems
| that preceded it.
On the other hand, the push/pull combination of spam and IM/SMS are well
on their way to killing Internet mail.  Spam being what it is, the
notion that anyone can send mail to anyone is naive.  Unsolicited mail
stands a good chance of ending up tossed by a spam filter.  The volume
of spam is so high that few people even bother to review the stuff
caught, if their mail provider even provides a mechanism to do that.

Meanwhile, the next generation of users is growing up on the immediacy
of IM and text messaging.  Mail is ... so 20th century.

I think the whole notion of decentralizing *everything* has turned out
to be a trap.  Yes, it makes for great cryptography and system design to
find ways to do without a trusted third party.  But the resulting
systems just don't fit the way people think and work.  Trust has
*always* been based on personal contact, extended to organizations that
work hard to have a human face on the one hand, and to various
human-scale, humanly-transparent ways of reifying and rendering portable
the smile and the handshake, from letters of credit to various business
rating organizations (DB, BBB), and so on.  Replacing that with some
abstract cryptographic system that no one understands, no one can see or
touch - and that ultimately can only be perceived as trustworthy if it
comes from trustworthy institutions anyway - is just a non-starter.

With this shaky base, it should perhaps not come as a surprise that
after all these years of trying, we haven't managed to come up with
human interfaces to these systems that actually allow them to work
effectively in the human world.

Meanwhile, in real terms, it would be interesting to know what
percentage of Email these days flows *between* organizations, and what
percentage remains within individual organization's Exchange servers.
With all the rules already enforced by typical Exchange-using
organizations - not to mention all the new rules being added as
first compliance and now evidence retention and destruction regs
and the upcoming information leakage management, more and more
Email systems are taking on the characteristics of the old closed
systems, with only a thin, closely watched pipe connecting them out
to the Internet.
-- Jerry

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


Re: Failure of PKI in messaging

2007-02-15 Thread Victor Duchovni
On Thu, Feb 15, 2007 at 10:10:21AM -0500, Leichter, Jerry wrote:

 Meanwhile, the next generation of users is growing up on the immediacy
 of IM and text messaging.  Mail is ... so 20th century.

Well, you certainly don't want to use email when coordinating a place to
meet in the next 10-15 minutes, while on the move with a cell phone, or
other near-real-time social activity so important to the next generation
while they are still the next generation.

I challenge the myth that this means that email won't be more important
to them as they mature.

 Meanwhile, in real terms, it would be interesting to know what
 percentage of Email these days flows *between* organizations, and what
 percentage remains within individual organization's Exchange servers.

I may be able to get you a data-point on that. Qualititatively external
email is not shrinking in significance here.

-- 

 /\ ASCII RIBBON  NOTICE: If received in error,
 \ / CAMPAIGN Victor Duchovni  please destroy and notify
  X AGAINST   IT Security, sender. Sender does not waive
 / \ HTML MAILMorgan Stanley   confidentiality or privilege,
   and use is prohibited.

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


Re: Failure of PKI in messaging

2007-02-15 Thread Nicolas Williams
On Thu, Feb 15, 2007 at 11:36:35AM -0500, Victor Duchovni wrote:
 On Thu, Feb 15, 2007 at 10:10:21AM -0500, Leichter, Jerry wrote:
  Meanwhile, the next generation of users is growing up on the immediacy
  of IM and text messaging.  Mail is ... so 20th century.
 
 Well, you certainly don't want to use email when coordinating a place to
 meet in the next 10-15 minutes, while on the move with a cell phone, or
 other near-real-time social activity so important to the next generation
 while they are still the next generation.

As mobile devices improve in compute/memory/display/input capabilities
the distinction between texting/IM/e-mail will get blurred, and at the
same time mobiles will become more and more tempting vehicle for
securing transactions.

E.g., I use the GMail J2ME app on my cell phone and it's almost as good
as SMS in some ways and better in others (plus I forward some e-mails to
SMS so that this app need not be running all the time).  I can even pay
via paypal using my phone, supposedly -- I've not tried it.

Just as we laugh when we recall 1980s cell phones (ha!) the next
generation will laugh at the best of our current crop of mobile devices,
never mind the more basic ones.

Nico
-- 

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


Re: Failure of PKI in messaging

2007-02-15 Thread Peter Saint-Andre

Leichter, Jerry wrote:


On the other hand, the push/pull combination of spam and IM/SMS are well
on their way to killing Internet mail.  


Video killed the radio star? I'm an IM partisan, but even I have given 
up on trying to kill off email.



Meanwhile, the next generation of users is growing up on the immediacy
of IM and text messaging.  Mail is ... so 20th century.


I prefer the phrase second-millennium. :-)


I think the whole notion of decentralizing *everything* has turned out
to be a trap.  


Interestingly, the public communication systems that are secure 
(Hushmail, Skype, etc.) are all centralized. I can't claim that a 
decentralized approach like Jabber is secure, though we're working on it...



Trust has
*always* been based on personal contact, extended to organizations that
work hard to have a human face on the one hand, and to various
human-scale, humanly-transparent ways of reifying and rendering portable
the smile and the handshake, from letters of credit to various business
rating organizations (DB, BBB), and so on.  Replacing that with some
abstract cryptographic system that no one understands, no one can see or
touch - and that ultimately can only be perceived as trustworthy if it
comes from trustworthy institutions anyway - is just a non-starter.


Can't agree more. (Not that agreement is the sine qua non of discussion.)


With this shaky base, it should perhaps not come as a surprise that
after all these years of trying, we haven't managed to come up with
human interfaces to these systems that actually allow them to work
effectively in the human world.


So how do we abstract from or extend what (somewhat) works in the real 
world to something that might work in the online world?


Peter

--
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Failure of PKI in messaging

2007-02-15 Thread John Levine
Suppose we have a messaging service that, like Yahoo, is
also a single signon service, ...

Then you just change the attack model.

There are a bunch of sites that do various things with your address
book ranging from the toxic Plaxo which slurps it up and sends spam to
everyone in it masquerading as an address change message from you to
more reasonable ones like LinkedIn which offers controlled messaging
to friends of friends.

Since typing in address book info by hand is hard, a lot of them sync
with your existing Outlook addressbook via a plugin, and some of them
also offer to sync with your Yahoo or or Gmail or Hotmail address
book.  What a bad idea -- those are single signon systems. If you've
ever bought anything at one of their hosted stores or use one of their
premium services, it's the same credential that lets people charge
stuff to your credit card.

It gets even messier.  Look at a configurable aggregator page like the
very spiffy Netvibes.  It has modules to check mail at AOL, MSN,
Yahoo, Gmail, and your POP provider, all conveniently remembering your
login info.  As far as I know Netvibes is reliable and competent, but
they have an extension API that lets anyone write extension modules
and offer them to Netvibes users.

I realize that readers of this list will use separate accounts for
financial info and free webmail, but the other 99.9% of people in
the world will be delighted that they only have one password to
write on a post-it rather than six.

It should be obvious why overloading phish protection onto this is an
equally bad idea -- it drops the security of the phish protection to
the security of the sleaziest aggregator module or address book site
that someone might use, and puts valuable financial and antiphish info
in the same security bucket as the three most recent subject lines
from your web mail.  Thanks, but no thanks.

R's,
John

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


Re: Failure of PKI in messaging

2007-02-15 Thread James A. Donald

--
John Levine wrote:
 What's missing is, if you'll pardon the phrase, a
 central point of failure.

 If you can persuade everyone to use a single system,
 it's not hard to make communication adequately secure.

But there is a central point.  ICANN is responsible for
internet names and numbers, and for keys to certify
those names and numbers, and it is pretty much
irrelevant.

Similarly, if everyone in the world used hushmail, would
not do any more good against phishing than if everyone
in the world used PKI signed mail - which is precisely
why people do not use PKI signed email.

You are making the Katrina reaction we need someone in
charge.  No, we do not need someone in charge.  Someone
in charge does not make everything right, more commonly
it makes everything wrong, disrupting, rather than
facilitating, communication and cooperation, just as
with the Katrina disaster.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 hHUR4oItlqyjOJrgB5g69WubFGEXSD2fFY+PslCK
 4pIw1gBia7di4K0uJB1p+FcZC9yxi1vCIFI3tot1u


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


Re: Failure of PKI in messaging

2007-02-15 Thread James A. Donald

--
Ed Gerck wrote:
 That's not banking. Banks and their clients already
 have a trusted relationship. The banks webmail
 interface leverages this to provide a trust reference
 that the user can easily verify (yes, this is my name
 and balance). That's why it works, and that's what is
 missing in the bank PKI email model -- what's that
 relationship buying you?

 Email for banks should thus leverage the relationship,
 rather than present an ab initio communication.

Hence my proposal for a single sign on and messaging
system resembling IM buddy lists - the computer tracks
relationship information, rather than true name
information.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 NMb/3lhm5wj1jn9bea0UJsViLkPWzA2jR+GCOgFV
 4WdwEv3Qp46Bt5AR7KTqFUUnJqu7E/XHnkKfJ2t/D

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


BETA solution, Re: Failure of PKI in messaging

2007-02-15 Thread Ed Gerck
James A. Donald wrote:
 Ed Gerck wrote:
 I am using this insight in a secure email solution that provides
 just that -- a reference point that the user trusts, both sending
 and receiving email. Without such reference point, the user can
 easily fall prey to con games. Trust begins as self-trust. Anyone
 interested in trying it out, please send me a personal email with
 application info.
 
 Want to try it out.  Not clear what you mean by application info.

The application info is just so I can verify your requirements.
The solution is in BETA and does not use Java, Flash, stored cookies,
or ActiveX. Works in Linux, Mac, and Win. There's also a javascript-
free version (earlier BETA).

The solution is available free (for personal use)
at https://zsentry.com/zmail/emailsecurity.html
Summary is available at http://zsentry.com and how it works at
https://zsentry.com/privacy_security_compliance_zmail.htm

The question is: Why should I trust it?

Zmail actually reduces the amount of trust by not storing your usercode,
password, or keys anywhere. This makes sense for zmail, and is an incentive
to actually do it, to reduce risk -- anyone breaking into any zmail server,
even physically, will not find any key or credential material for any user
and, hence, cannot decrypt any user area (the user area keeps the address book
and contact keys, all encrypted using the user keys that are not there), or
user messages collected from ISPs.

This is more than X.509 or PGP can do, as the private-key must be exposed
somewhere.

Next, let's see what zmail does. It creates a point-to-point encrypted
channel, with authentication, delivery and control mechanisms that you define.
It's a secure routing/delivery system, working as an add-on interface (so it
does not change how you use email).

The message itself could be encrypted by you and just delivered by zmail
-- so that you have the secure routing/delivery from zmail but do not have
to trust zmail with your plaintext.

This will actually be available in v3.x, with an option for client-based
super-encryption. If you are concerned about zmail peeking into the raw
message, which zmail does not do, you can simply agree with your message
partner on an out-of-band passphrase and use it in your client (without
zmail access) to encrypt. Your recipient can do the same to decrypt. What
you get from zmail is the secure routing and distribution -- for example,
you can require the recipient to login, allow the recipient to prevent
phishing, and expire the message in 7 days. You can also request a return
receipt telling you when, where, how, and by whom the message was decrypted.

While version 3x is not there, or even afterwards, you can do the same with
any publicly available file encryption and just attach the encrypted file
or paste its ASCII into the message panel. You don't have to worry about
user registration, anti-phishing, authentication, delivery control or use,
as all this (and more) is handled by zmail.

Thank you for your interest and I look forward to your feedback.

Best,
Ed Gerck

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


Re: Failure of PKI in messaging

2007-02-15 Thread John Levine
  If you can persuade everyone to use a single system,
  it's not hard to make communication adequately secure.
 ...

You are making the Katrina reaction we need someone in
charge. ...

Oh, not at all. I guess I wasn't clear.  To the extent that people use
a single system it can be secure, but that doesn't scale.  I have a
rule of thumb that any walled garden big enough to be interesting is
probably also big enough that bad guys have snuck in.

R's,
John


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


Re: Failure of PKI in messaging

2007-02-13 Thread Ian G

Steven M. Bellovin wrote:

On Mon, 12 Feb 2007 17:03:32 -0500
Matt Blaze [EMAIL PROTECTED] wrote:


I'm all for email encryption and signatures, but I don't see
how this would help against today's phishing attacks very much,
at least not without a much better trust management interface on
email clients (of a kind much better than currently exists
in web browsers).

Otherwise the phishers could just sign their email messages with
valid, certified email keys (that don't belong to the bank)
the same way their decoy web traffic is sometimes signed with
valid, certified SSL keys (that don't belong to the bank).

And even if this problem were solved, most customers still
wouldn't know not to trust unsigned messages purporting
to be from their bank.



Precisely.  The real problem is the human interface, where we're asking
people to suddenly notice the absence of something they're not used to
seeing in the first place.



Actually, there are many problems.  If you ask the low-level 
crypto guys, they say that the HI is the problem.  If you 
ask the HI guys, they say that the PKI concept is the 
problem.  If you ask the PKI people, they say the users are 
not playing the game, and if you ask the users they say the 
deployment is broken ...  Everyone has got someone else to 
blame.


They are all right, in some sense.  The PKI concepts need 
loosening up, emails should be digsig'd for authentication 
(**), and the HI should start to look at what those digsigs 
could be used for.


But, until someone breaks the deadly embrace, nothing is 
going to happen.  That's what James is alluding to:  what 
part can we fix, and will it help the others to move?


iang

** I didn't say digital signing ... that's another problem 
that needs fixing before it is safe to use, from the ask 
the lawyers basket.


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


Re: Failure of PKI in messaging

2007-02-13 Thread Ben Laurie
Ian G wrote:
 Steven M. Bellovin wrote:
 On Mon, 12 Feb 2007 17:03:32 -0500
 Matt Blaze [EMAIL PROTECTED] wrote:

 I'm all for email encryption and signatures, but I don't see
 how this would help against today's phishing attacks very much,
 at least not without a much better trust management interface on
 email clients (of a kind much better than currently exists
 in web browsers).

 Otherwise the phishers could just sign their email messages with
 valid, certified email keys (that don't belong to the bank)
 the same way their decoy web traffic is sometimes signed with
 valid, certified SSL keys (that don't belong to the bank).

 And even if this problem were solved, most customers still
 wouldn't know not to trust unsigned messages purporting
 to be from their bank.


 Precisely.  The real problem is the human interface, where we're asking
 people to suddenly notice the absence of something they're not used to
 seeing in the first place.
 
 
 Actually, there are many problems.  If you ask the low-level crypto
 guys, they say that the HI is the problem.  If you ask the HI guys, they
 say that the PKI concept is the problem.  If you ask the PKI people,
 they say the users are not playing the game, and if you ask the users
 they say the deployment is broken ...  Everyone has got someone else to
 blame.
 
 They are all right, in some sense.  The PKI concepts need loosening up,
 emails should be digsig'd for authentication (**), and the HI should
 start to look at what those digsigs could be used for.
 
 But, until someone breaks the deadly embrace, nothing is going to
 happen.  That's what James is alluding to:  what part can we fix, and
 will it help the others to move?
 
 iang
 
 ** I didn't say digital signing ... that's another problem that needs
 fixing before it is safe to use, from the ask the lawyers basket.

Perfectly safe to use in the UK. But sorry, I forgot that only the US
exists.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

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


Re: Failure of PKI in messaging

2007-02-13 Thread Anne Lynn Wheeler

Ian G wrote:
Actually, there are many problems.  If you ask the low-level crypto 
guys, they say that the HI is the problem.  If you ask the HI guys, they 
say that the PKI concept is the problem.  If you ask the PKI people, 
they say the users are not playing the game, and if you ask the users 
they say the deployment is broken ...  Everyone has got someone else to 
blame.


They are all right, in some sense.  The PKI concepts need loosening up, 
emails should be digsig'd for authentication (**), and the HI should 
start to look at what those digsigs could be used for.


But, until someone breaks the deadly embrace, nothing is going to 
happen.  That's what James is alluding to:  what part can we fix, and 
will it help the others to move?


iang

** I didn't say digital signing ... that's another problem that needs 
fixing before it is safe to use, from the ask the lawyers basket.


looking at the ssl domain name certificate uptake scenario ... there was
a combination of things ... lots of publicity so that consumers perceived it 
providing
some benefit, merchants perceiving that the consumers would feel better about
it ... and therefor (for merchants) that it was worthwhile to shell out the 
money ... and
lots of financial interests providing for publicity and support to have
it ubiquitously deployed (to encourage merchants to shell out the money).
lots of past posts mentioning the whole ssl domain name certificate 
scenario

http://www.garlic.com/~lynn/subpubkey.html#sslcert

part of the problem was that the PKI financial model is out of kilter with
standard business practices. nominally a relying party has some sort of
relationship with the certification authority (i.e. what they are
relying on) and there is exchange of value between the two parties.

In the standard PKI model, there frequently is absolutely no relationship
between the relying party and the certifying agency. The owner of the
digital certificate is paying the certifying agency ... not the relying
party ... so there is typically no exchange of value between the
certifying agency and the relying party ... and therefor the 
relying party has no foundation for actually relying on the certifying 
agency.


In early 90s ... there was some attempt to sidestep the lack of business
foundation for PKI ... by defining X.509 identity certificates, frequently 
grossly overloaded with personal information and then getting gov. regulations 
mandating the certificates. There were also attempts to up the anty

with semantic confusion attempting to equate digital signatures
with human signatures. misc. past posts about helping word
smith various electronic signature legislation and/or the wide
divide between digital and human signatures.
http://www.garlic.com/~lynn/subpubkey.html#signature

Remember that the (late 80s and) early 90s (with the attempts at ISO x.509 
identity
certificates) was also in the period when you saw various institutions
and govs. mandating the elimination of the internet and its replacement
with ISO (OSI model) networking standards.

one might even contend that in the ssl domain name certificate scenario ...
that once all the hype and publicity is stripped away ... that a fundamental
issue is that the relying party has absolutely no recourse with regard
to the certifying agency when things go wrong (which would exist in normal
business relationship between two parties). That the padlock symbol
is purely a representation of the hype and publicity ... and not a fundamental
business foundation.

recent thread about one of the major, fundamental justifications for ssl domain 
name
certificates ... countermeasure to man-in-the-middle attacks ... and not being
very effective
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL

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


Re: Failure of PKI in messaging

2007-02-13 Thread Ivan Krstić
Ian G wrote:
 Actually, there are many problems.  If you ask the low-level crypto
 guys, they say that the HI is the problem.  If you ask the HI guys, they
 say that the PKI concept is the problem.  If you ask the PKI people,
 they say the users are not playing the game, and if you ask the users
 they say the deployment is broken ...  Everyone has got someone else to
 blame.

This is, in my experience, exactly right. I'm trying to take some steps
for the better on the OLPC: all e-mails and IMs will be signed
transparently and by default, with the possibility of being encrypted by
default in countries where it's not a problem. This'll help with privacy
and message integrity, but it's not designed to stop phishing or
impersonation.

Phishing is less of an immediate problem for us, as there's little
incentive to phish 6-year olds in developing countries. But it will be a
problem eventually, and by then, it might be extremely difficult to
introduce sweeping changes in the security and HCI model to remedy the
problem.

One tremendous advantage we have now with OLPC is the ability to ignore
backwards compatibility for a number of things, so if we had a really
good model for dealing with phishing and the like -- even if it required
new assumptions or approaches -- we could probably do it. So maybe it's
time (for us, perhaps) to organize a workshop on this? Is there a better
way to do it?

-- 
Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D

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


Re: Failure of PKI in messaging

2007-02-13 Thread Ed Gerck

The solution is simpler than it seems.

Let's first look at one scenario that is already working
and use it as an example to show how the email scenario
may work.

Banks are already, and securely, sending and receiving
online messages to/from their clients. This is done by
a web interface, after the user logs in to their account.

Web user login can be based on a number of two-factor and
mutualauthentication solutions, some of them quite ineffective
to prevent phishing but, nonetheless, better than what the
email PKI model provides.

What's missing with the email PKI model?

While the bank is asking to be authenticated by the user, it
does so by asking the user to rely on a number of third-party
references that are actually unreliable (ie, by being without
recourse, warrantless, unverifiable, and chosen by the purported
sender in what may be a con game). The bank would never allow
the user to be authenticated under the same assumptions!

So, what's missing in the email PKI model is two-sidedness.
Fairness.

It is essential to have a reference point that the user trusts.
In the web messaging example already used by banks, this is
provided by the user login -- the user trusts that that is their
account -- their name is correct, their balance and transactions
are correct.

I am using this insight in a secure email solution that provides
just that -- a reference point that the user trusts, both sending
and receiving email. Without such reference point, the user can
easily fall prey to con games. Trust begins as self-trust. Anyone
interested in trying it out, please send me a personal email with
application info.

Best,
Ed Gerck

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


Re: Failure of PKI in messaging

2007-02-12 Thread Matt Blaze

I'm all for email encryption and signatures, but I don't see
how this would help against today's phishing attacks very much,
at least not without a much better trust management interface on
email clients (of a kind much better than currently exists
in web browsers).

Otherwise the phishers could just sign their email messages with
valid, certified email keys (that don't belong to the bank)
the same way their decoy web traffic is sometimes signed with
valid, certified SSL keys (that don't belong to the bank).

And even if this problem were solved, most customers still
wouldn't know not to trust unsigned messages purporting
to be from their bank.

-matt

On Feb 12, 2007, at 16:43, James A. Donald wrote:


 --
Obviously financial institutions should sign their
messages to their customers, to prevent phishing.  The
only such signatures I have ever seen use gpg and come
from niche players.

I have heard that the reason no one signs using PKI is
that lots of email clients throw up panic dialogs when
they get such a message, and at best they present an
opaque, incomprehensible, and useless interface.  Has
anyone done marketing studies to see why banks and
massively phished organizations do not sign their
messages to their customers?

 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  BwrcLrYHszR0syC9LdVrjxAionyxVDwbtJq8Xu2q
  4ky71ODjPeHF5TC4pnkktFaLHEOfFN4fY8JEyqnfn

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


Re: Failure of PKI in messaging

2007-02-12 Thread Steven M. Bellovin
On Mon, 12 Feb 2007 17:03:32 -0500
Matt Blaze [EMAIL PROTECTED] wrote:

 I'm all for email encryption and signatures, but I don't see
 how this would help against today's phishing attacks very much,
 at least not without a much better trust management interface on
 email clients (of a kind much better than currently exists
 in web browsers).
 
 Otherwise the phishers could just sign their email messages with
 valid, certified email keys (that don't belong to the bank)
 the same way their decoy web traffic is sometimes signed with
 valid, certified SSL keys (that don't belong to the bank).
 
 And even if this problem were solved, most customers still
 wouldn't know not to trust unsigned messages purporting
 to be from their bank.
 

Precisely.  The real problem is the human interface, where we're asking
people to suddenly notice the absence of something they're not used to
seeing in the first place.

Yes, there have been studies.  They've all been quite disappointing.
I'm working on some related material right now, with the financial
sector.  It's not an easy problem.



--Steve Bellovin, http://www.cs.columbia.edu/~smb

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