Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-27 Thread Ben Laurie
Anne  Lynn Wheeler wrote:
 James A. Donald wrote:
 However, the main point of attack is phishing, when an
 outsider attempts to interpose himself, the man in the
 middle, into an existing relationship between two people
 that know and trust each other. 
 
 in the public key model ... whether it involves pgp, pki, digital
 certificates, what-ever; the local user (relying party) has to have a
 local trusted repository for public keys. in the pki model, this tends
 to be restricted to public keys of certification authorities ... so that
 the relying party can verify the digital signature on these
 message/document constructs called digital certificates.
 
 in the traditional, ongoing relationship scenario, relying parties
 directly record authentication information of the parties they are
 dealing with. if a relying party were to directly record the public key
 of the people they are communicating with ... it is the trusting of that
 public key and the validating of associated public key operations that
 provide for the countermeasure for man-in-the-middle attacks and
 phishing attacks.
 
 the issue that has been repeatedly discussed is that supposedly the
 existing SSL domain name digital certificates was to prevent
 impresonation and mitm-attacks. however, because of various
 infrastructure shortcomings ... an attacker can still operate with
 perfectly valid SSL domain name digital certificates ... and it doesn't
 stop the MITM-attack and/or phishing.

Eh? It surely does stop MitM attacks - the problem is that there's
little value in doing so for various reasons, such as no strong binding
between domain name and owner, UI that doesn't make it clear which
domain you are going to, or homograph attacks.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
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: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-27 Thread Anne Lynn Wheeler
Ben Laurie wrote:
 Eh? It surely does stop MitM attacks - the problem is that there's
 little value in doing so for various reasons, such as no strong binding
 between domain name and owner, UI that doesn't make it clear which
 domain you are going to, or homograph attacks.

it stops the MITM attacks where the client supplies a URL and the server
supplies a certificate that corresponds to the URL.

the original issue is that a MITM might have redirected the connection
from the client to a bogus site ... or an intermediate site that then
impersonated the real site.

the infrastructure issue was that the merchants decided that SSL was too
high an overhead and stopped using SSL for the main connection where the
client supplied the URL. they allowed the client supplied URL connection
to be done w/o a URL. then later ... the website provided a click button
for checkout/pay ... which supplied a URL and then they also supplied a
certificate that matches the URL that they provided.

this situation could either be a completely bogus site ... or even a
mitm-attack ... which just did a pure passthru of all traffic going in
each way  except for the pay/checkout button. for the pay/checkout
button, the mitm substituted their own URL  certificate. everything
else passes thru as usual ... except the mitm is having two ssl session
... the mitm to real server session and the mitm to the client
session. the mitm to real server uses the real server's certificate
... the mitm to client server users the mitm certificate. since the mitm
supplied the URL to the client as part of the click operation ... the
mitm can control that the actual URL invoked by the client matches the
certitificate used by the mitm. the e-commerce use for pay/checkout
scenario is one of the major uses for SSL on the internet today ... and
the way that the infastructure has come to use SSL no longer prevents
the mitm-attack with the attacker can supply both the URL and the
certificate.

the issue for preventing mitm-attacks ... you need the client to supply
the URL and have the SSL process validate the other end of that
connection (with a server provided ssl domain name certificate ... or at
least a trusted, supplied public key associated with the URL). when the
attacker provides both the URL and a trusted public key ... what is
being prevented.

there is another problem, somewhat the week binding between domain name
and domain name owner. the issue is that many of the certification
authorities aren't the authoritative agency for the information they are
certifying. much of the original justification for SSL related to mitm
attacks was various integrity issues in the domain name infrastructure.

the process tends to be that a domain name owner registers some amount
of identification information for their domain name ownership with the
domain name infrastructure. the certification authorities then require
that SSL domain name certificate applicants also provide some amount of
identification information. then the certification authorities attempt
to do the expensive, time-consuming, and error-prone process of matching
the supplied identification information for the SSL domain name
certificate with the identificaiton information on file with the domain
name infrastructure for the domain name.

as part of various integrity issues related to that process, there has
been a proposal, somewhat backed by the ssl domain name certification
authority industry that domain name owners also register a public key
with the domain name infrastructure (in addition to identificaiton
information). then future communcation can be digitally signed and
verified with the onfile public key. also the ssl domain name
certification authority industry can require that ssl domain name
certificate applications be digitally signed. then the certification
authority can replace the expensive, time-consuming, and error-prone
identification matching process with a much less-expensive and efficient
authentication process by doing a real-time retrieval of the on-file
publickey from the domain name infrastructure for verifying the digital
signature (in lieu of doing a real-time retrieval of the on-file
identificaiton information for the expensive, time-consuming and
error-prone identification matching).

the two catch22 issues here are

1) improving the overall integrity issues of the domain name
infrastructure lessons the original justification for ssl domain name
certificates

2) if the certification authority industry can rely on real-time
retrieval of publickeys from the domain name infrastructure as the base,
TRUST ROOT for all of their operations ... it is possible that other
people in the world might also be able to do real-time retrieval of
publickeys as a substitute to relying on SSL domain name certificates

misc, numerous past postings mentioning SSL and ssl domain name certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-27 Thread Anne Lynn Wheeler
Ben Laurie wrote:
 Eh? It surely does stop MitM attacks - the problem is that there's
 little value in doing so for various reasons, such as no strong binding
 between domain name and owner, UI that doesn't make it clear which
 domain you are going to, or homograph attacks.

part II;

i've repeatedly asserted that the fundamental, underlying certificate
business practices is to address the first time communication between
complete strangers ... analogous to the letters of credit/introduction
from the sailing ship days.

so the original SSL design point was to cross-check the domain name from
the URL typed in by the client to the certificate supplied by the
server. that basic premise is underminned when the server supplies the
URL and the certificate.

so you are left with placing the burdon on the user to cross-check the
URL displayed with the URL they think they are going to. it is simple
human dynamics ... after the first several thousand displayed URLs ...
they are going to ignore the process.

this is somewhat akin to the share-secret passwords ... that the
security experts define that the user has to have hard-to-guess,
impossible-to-remember passwords that change every 30 days, can never be
written down and every new password has to be unique ... as well as
unique across all security domains. the problem is that the number of
unique security domains that a person deals with has grown from 1-2 (I
had my first logon password in the 60s followed with the addition of an
ATM pin in the late 70s) to scores ... there is no practical possibility
that all such requirements can be satisified. misc. past collected posts
on shared-secret
http://www.garlic.com/~lynn/subpubkey.html#secrets

the underlying infrastructure further complicated the whole process when
a large percentage of the merchants outsourced the payment process to
3rd party ... where the click button supplied a URL of the 3rd party
payment processor that had absolutely no relationship to the merchant
site the client had been shopping at. this not only creates the
situation where

1) any initial connection to a merchant site where the user might
possibly have typed in the URL (or controls the URL generation via other
mechanisms) is not checked ... and any actual checking for things like
MITM-attacks doesn't occur until there is a URL provided by a
potentially suspect site.

but also

2) conditions the user as normal process that the pay/checkout button
may have a complete different domain name URL than the domain name of
the shopping site.

so, pretty well documented human factors ... especially related to the
design of security systems ... is that you don't tie humans making
determination about soem security issue to something that repeatedly
happens thousands and thousands of times. there are some guards that
have to check badges against faces ... but they tend to have intensive
training AND organizations that have high volume have gone to guards
doing it only short periods and rotating ... and/or the guards are
looking for a very simple repeating pattern and are trained to look for
missing pattern). having the human have to repeatedly check a (URL)
field that changes several thousand times a day against something they
are suppose to expect ... is pretty quickly a useless security design.

a more sensible human factors design ... is to remember whether a person
has checked out first time communication with a stranger ... the real
first time, have the person do something additional ... and from then on
remember that checking. in that respect ... creating a dependency on the
user to repeatedly check a field that changes possibly thousands of
times per day is extremely poor human factors security design.

now, the other part of my constant theme about certificates having
design point of first time communication between complete strangers ...
involves the additional constraing that the relying party has no other
recourse to obtain information about the other party. if you go to
paradigm where the relying party has facilities to remember first time
checking ... then the appended certificate on the communication is
actually only useful for the real first-time-communication (since by
definition the relying party has facilities to remember previous
checking ... like saving away the other parties publickey in a trusted
public key repository).

another part is that if you have the relying party do some additional
checking on the real first time interaction (rather than expecting the
user to do increasingly trivial checking on each new URL) ... and the
user is really online ... then that first time checking can involve
real-time check of online resources  again invalidating more of the
underlying design point of appending a certificates on every
communciation for benefit of relying parties who have no other recourse
for determining information about complete stranger in first time
communication.

there is something of a dichotomy here ... where there 

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-27 Thread Ben Laurie
Anne  Lynn Wheeler wrote:
 a more sensible human factors design ... is to remember whether a person
 has checked out first time communication with a stranger ... the real
 first time, have the person do something additional ... and from then on
 remember that checking. in that respect ... creating a dependency on the
 user to repeatedly check a field that changes possibly thousands of
 times per day is extremely poor human factors security design.

This is the SSH design for host keys, of course, and also the petnames
design for URLs. Unfortunately petnames don't solve the problem that it
is hard to check the URL even the first time.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

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: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-27 Thread Anne Lynn Wheeler
Ben Laurie wrote:
 This is the SSH design for host keys, of course, and also the petnames
 design for URLs. Unfortunately petnames don't solve the problem that it
 is hard to check the URL even the first time.

the original SSL paradigm was predicated on end-to-end security that
the server the user thot they were taling to was the server that they
were actually talking to. certificates addressed the part from the URL
inside the browser to the server.

the paradigm was dependent on the user having a tight binding between
the server the user thot they were talking to and the URL inside the
browser ... which in turn was dependent on the user actually inputing
the URL (as demonstration of the binding between the server the user
thot they were talking to and the inputed URL).

the problem was that as the infrastructure matured ... the actual URL
came to have less  less meaning to the user. so the MITM-attacks moved
to the weak points in the chain ... rather than attacking a valid
certificate and/or the process after the URL was inside the browser,
attack the process before the URL got inside the browser.

petnames would seem to suffer somewhat the same problem as
shared-secrets and passwords ... requiring a unique petname for every
URL. it works as long as their a few ... when they reach scores ... the
user no longer can manage.

so part of the problem is that the URL has become almost some internal
infrastructure representation... almost on par with the ip-address ...
the user pays nearly as much attention to the URL for a website as they
pay to the lower-level ip-address for the site (legacy requirements
still have ways for people to deal with both the URL and the ip-address
... but they don't have a lot of meaning for a lot of people).

however the URL Is one way of internally doing bookkeeping about a site.

so security issues might be

1) is the user talking to the server they think they are talking

2) does the user believe that the site is safe

3) is the site safe for providing certain kinds of sensitive information

4) is the site safe for providing specific sensitive information

#1 is the original SSL design point ... but the infrastructure has
resulted in creating a disconnect for establishing this information.

possibly another approach is that the local environment remembers things
... akin to PGP key repository. rather than the SSL locked ... have a
large green/yellow/red indicator. red is neither SSL locked and/or
checked. yellow is both SSL locked and checked.  green is SSL loaked,
initial checked, and further checked for entry of sensitive information.

a human factors issue is how easy can you make preliminary checking ...
and then not have to do it again ... where the current infrastructure
requires users to match something meaningful to URL to SSL certificate
on every interaction. preliminary checking is more effort than the
current stuff done on every SSL URL ... but could be made to be done
relatively rarely and part of an overall infrastructure that directly
relates to something the end-user might find meaningful.

bits and pieces of the infrastructure is already there. for instance
there is already support for automatically entering userid/password on
specific web forms. using bits and pieces of that repository could
provide ability to flag a specific web form as approved/not-approved for
specific sensitive information (like specific userid/password).

the issue isn't that a simple indicator with 2-4 states isn't useful ...
but the states presented need to realistic need to mean something to the
user. the locked/unlocked just says that the link is encrypted. it
doesn't indicate that the remote site is the server that that the user
thinks it is ... in part because of the way that the infrastructure has
creating disconnect between the URL and what users actually deal in.

if the browser kept track of whether the user actually hit the keys for
the entering of the URL ... then it might be useful for the browser to
provide a higher level of confidence to the SSL certificate checking
(aka it is only if the user actually typed in the URL ... can their be a
high-level of confidence related to the SSL certificate checking).

one might be tempted to make some grandiose philosophical security
statement ... that unless the user is involved in actually doing some
physical operation (at least at some point in time) to correlate between
what is meaningful to the user and the internal infrastructure. the
original SSL scheme was dependent on the user actually typing in the URL.

this is somewhat analogous to the confusion that seems to have cropped
up in the past with respect to the difference between digital signature
and human signature.
http://www.garlic.com/~lynn/subpubkey.html#signature

x9.59
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

could actually have digital signature applied to a retail transaction at
point-of-sale as means of authentication. 

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-16 Thread James A. Donald
--
From:   Werner Koch [EMAIL PROTECTED]
 You need to clarify the trust model.  The OpenPGP
 standard does not define any trust model at all.  The
 standard merely defines fatures useful to implement a
 trust model.

Clarifying the trust model sounds suspiciously like
designers telling customers to conform to designer
procedures.  This has not had much success in the past.

People using PGP in practice verify keys out of band,
not through web of trust.

People using https tend to click through. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 9zzvV5qgyWeB4uTJn5vTjFtKeouMk46hiM0EN7Q+
 4CKg4nhwvcBjl855xVUXY5XMP46ZdvXoOl8Wu0Hyb



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-16 Thread Ed Gerck

James A. Donald wrote:

--
From:   Werner Koch [EMAIL PROTECTED]

You need to clarify the trust model.  The OpenPGP
standard does not define any trust model at all.  The
standard merely defines fatures useful to implement a
trust model.


Clarifying the trust model sounds suspiciously like
designers telling customers to conform to designer
procedures.  This has not had much success in the past.

People using PGP in practice verify keys out of band,
not through web of trust.


James,

Yes. Your observation on out-of-band PGP key verification
is very important and actually exemplifies what Werner
wrote. Exactly because there's no trust model defined
a priori, uses can choose the model they want including
one-on-one trust.

This is important because it eliminates the need for a
common root of trust -- with a significant usability
improvement.

If the web of trust is used, the sender and recipient must
a priori trust each other's key signers, requiring a
common root of trust -- that may not even exist to begin
with.

So, instead of worrying about what trust model PGP uses,
the answer is that you can use any trust model you want --
including a hierarchical trust model as used with X.509.

Jon Callas and I had several conversations on trust in
May '97, when Jon visited me for two weeks while I was
in Brazil at the time, I think before the OpenPGP WG was
even working on these issues. This is one of the comments
Jon wrote in a listserv then, with a great insight that
might be useful today:

  As I understand it, then, I've been thinking about some
  of the wrong issues. For example, I have been wondering
  about how exactly the trust model works, and what trust
  model can possibly do all the things Dr Gerck is claiming.
  I think my confusion comes from my asking the wrong
  question. The real answer seems to be, 'what trust model
  would you like?' There is a built in notion (the
  'archetypical model' in the abstract class) of the meta-
  rules that a trust model has to follow, but I might buy a
  trust model from someone and add that, design my own, or
  even augment one I bought. Thus, I can ask for a
  fingerprint and check it against the FBI, Scotland Yard,
  and Surite databases, check their PGP key to make sure
  that it was signed my Mother Theresa, ask for a letter of
  recommendation from either the Pope or the Dalai Lama
  (except during Ramadan, when only approval by the Taliban
  will do), and then reject them out of hand if I haven't had
  my second cup of coffee.

Cheers,
Ed Gerck



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-14 Thread Werner Koch
On Mon, 12 Dec 2005 10:59:05 -0600, Travis H said:

 Not to side track the discussion, but frequently I've heard PKI
 compared to PGP's model.  Isn't PGP's trust model the same as everyone
 being their own CA?

You need to clarify the trust model.  The OpenPGP standard does not
define any trust model at all.  The standard merely defines fatures
useful to implement a trust model.

AFAIK, PGP provides two different trust models; with GnuPG you may
also select between 4 trust models.  However this is implementation
specific and not part of the standard. 

The classic web of trust is just the commonly used one.  It is a
pity that many commonly used mail programs don't even make use of any
real trust model but use the always trust model.

The newer trust model pgp makes use of the advanced OpenPGP features
and allows implementing a hierarchical model very similar to the X.509
one.  In fact it is a superset of the X.509 model.



Salam-Shalom,

   Werner





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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Anne Lynn Wheeler
Ed Gerck wrote:
 I think that's where PKI got it wrong in several parts and not
 just the CPS. It started with the simplest (because it was meant to
 work for a global RA -- remember X.500?) and then complexity was
 added. Today, in the most recent PKIX dialogues, even RFC authors
 often disagree on what is meant in the RFCs. Not to mention the
 readers.

the baseline analysis, threat/vulnerability models, etc ... start with
the simplest and then build the incremental pieces  frequently
looking at justification for the additional complexity.

when doing the original design and architecture you frequently start
with the overall objective and do a comprehensive design (to try and
avoid having things fall thru the cracks).

i would contend that the issue with PKI isn't as much that they started
with simple and then did incremental piece-meal design (rather than
complete, comprehensive design) ... but they actually did design
something for a specific purpose ... and subsequently it was frequently
tried to force-fit it for purposes for which it wasn't originally
designed for.

for example the traditional business model tends to have relying parties
contracting directly with the parties they rely on (and there is
contractual obligation between the two parties). the evolution of the
trusted third party certification authority model violates most standard
business practices that have grown up over hundreds of years.

the trusted third party certification authority is selling digital
certificates to key owners for the benefit of relying parties. there is
a large disconnect where the parties that are supposedly going to rely
on and benefit from the digital certificates aren't the ones contracting
for the digital certificates. this disconnect from standard business
practices can be considered the motivating factor for the invention of
CPS ... even tho there may not be a direct business and contractual
relationship between the relying parties and the certification
authorities ... a CPS tries to fabricate a sense of comfort for the
relying parties. A contractual relationship would otherwise provide for
this sense of trust... the relying party pays the certification
authority for something, and the certification authority then has some
obligation to provide something in return to the relying party.
In most trusted third party certification authority operations there is
no legal, business or otherwise binding relationship between the
relying party and the TTP/CA ... it is between the key owner and the TTP/CA.

This could be further aggravated by RFC authors who possibly have no
familiarity with standard business practices and attempt to write
something just because they want it to be that way.

Another example could be considered OCSP. Basically digital certificates
are stale, static, r/o, armored copies of some information located
someplace. A business process model has relying parties, relying on the
information in stale, static, r/o copies of the information because they
have no means for directly accessing the real, original information
(basically the letters of credit/introduction from sailing ship days ...
aka offline with no local resources). OCSP provides for a online
transaction which asks whether the stale, staic information is still
usuable, attempting to preserve the facade that digital certificates
serve some useful purpose when there is online, direct access
capability. The alternative is to eliminate the digital certificates all
together and rather than doing an OCSP transaction, do a direct, online
transaction.

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Ed Gerck

Anne  Lynn Wheeler wrote:

OCSP provides for a online
transaction which asks whether the stale, staic information is still
usuable, attempting to preserve the facade that digital certificates
serve some useful purpose when there is online, direct access
capability. The alternative is to eliminate the digital certificates all
together and rather than doing an OCSP transaction, do a direct, online
transaction.


The benefits of not always requiring direct online transactions has been
pointed out before in this thread, in terms of anonymity, availability and
reliability. What happens when you get a message and the direct, online
connection isn't there? You can' decrypt it even though it you need to?

Digital certs (X.509 and PGP) are useful when the key owner is not online.
There is a world when this not only happens but is also useful. BTW, this
is recognized in IBE as well.

A couple additional comments:

 the baseline analysis, threat/vulnerability models, etc ... start with
 the simplest and then build the incremental pieces  frequently
 looking at justification for the additional complexity.

 when doing the original design and architecture you frequently start
 with the overall objective and do a comprehensive design (to try and
 avoid having things fall thru the cracks).

Agreed, and that's where a baseline analysis really fails to reveal a
design's pros and cons -- because it follows a different path. Seems
logical but denies the design's own logic (which did NOT use a baseline
approach to begin with, on purpose).

Therefore, when I look into X.509 / PKI issues, or secure email issues,
a baseline analysis is not so very useful.

 the trusted third party certification authority is selling digital
 certificates to key owners for the benefit of relying parties.

The RPs are not part of the contract. Without CAs, there's no key
owner in PKI. It's for the benefit (and reduction of liability)
of the key owners.

Cheers,
Ed Gerck

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Ralf Senderek
On Fri, 9 Dec 2005, Ed Gerck wrote:

 [...]  at least the grand
 picture should exist beforehand. This is what this thread's subject
 paper is about, the grand picture for secure email and why aren't
 we there yet (Phil's PGP is almost 15 years old) -- what's missing.
 

and Bill Stewart wrote:

 Popularity of a product is critical to its security;
 you don't gain anonymity if the Feds can recognize that
 you're one of the dozen users of a given application.
 Your mom can use Skype, but nobody she knows uses Crypto Kong,
 and I only know a few people who use PGP to email their mom.
 But some of the Instant Messaging systems use crypto;
 too bad that they're continually trying to be incompatible
 with each other to gain market share.

I think what's missing is the understanding that there cannot be
secure email without the persons involved acting responsible and 
knowing their role in the process.
Your mother will probably expect the computer to do the job for her
(mine will never expect anything from computers) rejecting any
responsibility for her email's security. In my opinion establishing
secure email this way is impossible despite the fact that encryption is
(relatively) easy if our algorithms work as expected and you have the
correct high-quality public key.
And even if Instant Messaging systems would use the same crypto people
will use them like cell phones without any consciousness of their own
responsibility for key validation. Getting good crypto into mass products
can help but does not eliminate the necessity for checking essential properties
of the system they use.
How we can make this job as reliable as possible is the question at the heart
of the problem.


Ralf Senderek


*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek  [EMAIL PROTECTED] http://senderek.com*  What is privacy  *
* Sandstr. 60   D-41849 Wassenberg  +49 2432-3960   *  without  *
* PGP: AB 2C 85 AB DB D3 10 E7  CD A4 F8 AC 52 FC A9 ED *Pure Crypto?   *
49466008763407508762442876812634724277805553224967086648493733366295231438448

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread James A. Donald
--
James A. Donald wrote:
  However, the main point of attack is phishing, when
  an outsider attempts to interpose himself, the man
  in the middle, into an existing relationship between
  two people that know and trust each other.

Anne  Lynn Wheeler [EMAIL PROTECTED]
 in the traditional, ongoing relationship scenario,
 relying parties directly record authentication
 information of the parties they are dealing with. if a
 relying party were to directly record the public key
 of the people they are communicating with ... it is
 the trusting of that public key and the validating of
 associated public key operations that provide for the
 countermeasure for man-in-the-middle attacks and
 phishing attacks.

This was the scenario envisaged when PKI was created,
but I don't see it happening, and in fact attempting to
do so using existing user interfaces is painful.  They
don't seem designed to do this.

My product, Crypto Kong, http://echeque.com/Kong was
designed to directly support this scenario in a more
convenient fashion - it keeps a database of past
communications and their associated keys, but there did
not seem to be a lot of interest.   I could have made it
more useful, given it more capabilities, but I felt I
was missing the point 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 4ostZwIWJbNX6/eRYYX4QMLG5GGNUaPJao5ZKKGB
 4Bt20kCp2fkd6wgjBDjYMz5ZqUEnTYL4O3aTalDOB



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Anne Lynn Wheeler
James A. Donald wrote:
 This was the scenario envisaged when PKI was created,
 but I don't see it happening, and in fact attempting to
 do so using existing user interfaces is painful.  They
 don't seem designed to do this.
 
 My product, Crypto Kong, http://echeque.com/Kong was
 designed to directly support this scenario in a more
 convenient fashion - it keeps a database of past
 communications and their associated keys, but there did
 not seem to be a lot of interest.   I could have made it
 more useful, given it more capabilities, but I felt I
 was missing the point 

i've seen some discussions that were either/or regarding pki  pgp;
aka pki advocates attempting to position pki as a OR to pgp. the issue
is that both pki and pgp require a local trusted public key repository
as the basis for establishing trust.

pki then layers on it, these certification authority business processes,
specialized digitally signed messages called digital certificates, etc
to address first time communication between strangers where the relying
parties have no other resources for determining information about the
sender in an offline environment. they then advocate that all
(personally) digitally signed operations are required to have attached
x.509 identity digital certificates that has been digitally signed by a
certification authority.

we saw some of that when we did work on the cal. state  fed. electronic
signature legislation
http://www.garlic.com/~lynn/subpubkey.html#signature

one possible interpretation might be that it would have increased the
revenue stream for the certification authority industry.

drastically improving the useability of the interface to the trusted
public key repositories could be viewed as having two downsides 1)
certification authorities that haven't payed to have their public keys
preloaded can more easily join the club, 2) the pgp-like scenario
becames much easier, potentially drastically reducing existing reliance
on the digital-certificate-only (and certification authority only
business process) digital-signed-operation model.

part of the problem with the trusted third party certification authority
 model is that its primary benefit in the case of first time
communication betweeen two strangers ... where the relying party has no
other recourse to information about the other party. this is actually an
extremely small percentage of communications. we saw some of this
working on the original e-commerce activity
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

where we layed out hypothetical certification issues for merchants ...
including things like having FBI background checks for all merchant
employees. the problem is that e-commerce transactions have been quite
bi-model whith the largest percentage of transaction occuring as repeat
business with well-known merchants. in these cases, consumers have
established trust via a large number of other mechanisms ... so there is
little added value that a certification authority can provide ...
especially if they aren't willing to stand-behind and guarantee all
merchant transactions (ssl then is primarily countermeasure to
mitm-attack and evesdropping on transaction as opposed to a
certification/trust issue).

the rest of the remaining transaction are spread around to a large
number of different merchants having a few transactions each. the issue
here is that the incremental revenue flow for a few transactions a month
couldn't possibly cover the cost of a certification process that
involved things like fbi background checks on all merchant employees.

the large majority of transactions are either repeat business and/or
with extremely well-known merchants ... this doesn't satisfy the PKI
target profile of first time communication between complete strangers.
simple countermeasure to mitm-attack and countermeasure is achieved by
having stored the merchant's public key (from the consumer's standpoint).

from the merchant standpoint they already have transaction guarantees on
credit card processing from their contract with financial institution.
the threat/vulnerability model here is client-originated fraudulent
transactions that aren't strongly authenticated. here, x9.59 standard
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

allows for digitally signed transaction where the public key is
registered with the consumer's financial institution and the digital
signature is verified by the consumer's financial institution as part of
verifying the transaction.

the other part of x9.59 standard is that it specifies that account
numbers used in x9.59 transactions can't be used in non-authenticated
transactions. this eliminates both data breaches and evesdropping as a
threat/vulnerability for fraudulent financial transactions ... aka the
requirement given the x9a10 working group for x9.59 standard was to
preserve the integrity of the financial infrastructure for all retail

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread James A. Donald
--
From: Bill Stewart [EMAIL PROTECTED]
 The real security issue for your mother is [...] her  
 bank and eBay don't cryptographically sign their mail.

And, since her bank and ebay are under massive attack  
from phishers, and your mother, if she is using any of  
the common email clients is using a cryptographically  
enabled mail agent, why don't they sign their email?  
This is exactly the attack that PKI was designed to  
address.

My possibly biased answer to this question, based on my 
past job as key keeper for two companies, would be that 
not only can your mother not sign her stuff with PKI,  
but the chairman of the board finds it even harder.

Does anyone else have war stories on this issue?

Just as big companies find it hard to write software  
that does not open their servers to a cross scripting  
attack, and hard to interact with their users in ways  
that do not train their users to respond to phishing  
attacks, and hard to write server side software that  
does not rely on the behavior of client side forms, they 
also find it hard to sign their email.

In the unlikely event that my mother is threatened by  
man in the middle attacks, she will allow me to set up  
secret key on her computer, and will follow my  
instructions on how to use it, but the chairman of the  
board will not, nor will the marketing department.

That is my experience - does anyone else have any  
experience that differs from this, or confirms this?

And before we sneer at the chairman of the board - hands 
up all programmers who failed to client and server side 
disable all past cookies and issue new https and http  
cookies on receiving a valid login, and all programmers 
who failed to enumerate and sterilize all fields  
appearing in any response.

It is not my position that inability to sign means that 
the chairman of the board is stupid.  It is that  
cryptographic signatures are too @#$%^* hard and need 
to be made user friendly.

First write software that is easy enough for your 
mother.  Then we can work on making it easy enough for 
the marketing department.  

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 gvDLBPaNQFZ3Y0yhzmO2KnYEKGolt9E+eey2rPxE
 4bGpW6AUGiMGbJFzaXJ8QcBY0HMhbypcque+5LrMd



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread James A. Donald
--
From:  Anne  Lynn Wheeler [EMAIL PROTECTED]
 drastically improving the useability of the interface 
 to the trusted public key repositories could be viewed 
 as having two downsides 1) certification authorities 
 that haven't payed to have their public keys preloaded 
 can more easily join the club, 2) the pgp-like 
 scenario becames much easier, potentially drastically 
 reducing existing reliance on the 
 digital-certificate-only (and certification authority 
 only business process) digital-signed-operation model.

I would state the same thing differently:  That the 
revenue model is based on sprinkling holy water over 
communications, rather than actually providing security.

Hence the proposal to address phishing by providing 
higher priced grades of holy water.

Public keys are relevant to the problem of decentralized 
reputation management.  For relationship management, 
shared secrets are better.   At present, the only widely 
applied reputation management software is that possessed 
by Ebay - which uses centralized reputation management 
software, so that it can charge people a fee for making 
use of their own reputations, and thus has no inherent 
need or desire for public keys.

After all these years, we still do not have a good fit 
between the capabilities of the technology, the 
usability of the interface, and the problems people need 
solved. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 X1okruQ3BE+qbWjk1b7CgXMbsiKNhvf5oMKDgR71
 4cxizGKqHfxeifgKTUEvpkLYq7wSgzAckTy2yLzQ8



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread James A. Donald
--
From:   Ed Gerck [EMAIL PROTECTED]
 Digital certs (X.509 and PGP) are useful when the key
 owner is not online. There is a world when this not
 only happens but is also useful. BTW, this is
 recognized in IBE as well.

But the key owner is always online, for in practice,
certs are always used for https.

Arguably we should be using not-necessarily-online certs
to sign email, but the email that arguably needs
signing, for example emails from amazon.com, are never
signed.

The only reason this email is signed is to make a point
about technology, not because the signature serves any
useful purpose.

 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 ca4N69sv32Q/plWYe5BnvcydTDFaMVJkZ0rPbVp6
 4CRaaWK8UP3bCPHDbDzuPW7zEKImu5L9x7RUMIrbG



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread Travis H.
Not to side track the discussion, but frequently I've heard PKI
compared to PGP's model.  Isn't PGP's trust model the same as everyone
being their own CA?

I find PGP to be problematic.  Many keys I see are only self-signed,
and this includes important keys like CERT.  Many others sit unsigned
on the same website you access to download the source code protected
by it.  And 90% of the time when they have more than one signature you
don't have a key that signed the other party's key, so you get to do a
breadth-first search manual-like (pathserver being dead and all). 
Even with kgpg pulling the keys from a keyserver for you, it's still
non-trivial.

I successfully inspired a local keysigning, but it seems like most of
the people didn't see any immediate benefit, and so declined to
participate.  What does this mean for me was a common question.  I
tried to explain the purpose, but I suspect it is too recondite or too
far removed from their experience.  Perhaps I'd have better luck by
stating what kind of attacks it would prevent (email spoofing being
relatively rare, save for some obvious spam tactics).  I'm open to any
suggestions along these lines.
--
http://www.lightconsulting.com/~travis/  -- P=NP if (P=0 or N=1)
My love for mathematics is unto 1/x as x approaches 0.
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-12 Thread James A. Donald
--
From:  Ralf Senderek [EMAIL PROTECTED]
 I think what's missing is the understanding that there 
 cannot be secure email without the persons involved 
 acting responsible and knowing their role in the 
 process. Your mother will probably expect the computer 
 to do the job for her (mine will never expect anything 
 from computers) rejecting any responsibility for her 
 email's security. In my opinion establishing secure 
 email this way is impossible despite the fact that 
 encryption is (relatively) easy if our algorithms work 
 as expected

This sounds like it is not my fault.  It is those 
stupid user's fault

No, it is not those stupid user's fault.  It is our
fault.  For example phishing ought not to be possible -
would not be possible if we used zero knowledge
technologies to protect passwords.

Whenever a user communicates anything to anyone, they 
use a password, or some form of shared secret - their 
credit card number - the password whereby they login to 
their mail server. Therefore, whenever a user 
communicates anything to anyone, it should be secure, 
but it is not. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Jogksi+CFTLv6yHXLYAd6VeQz73gNHYNM1t/B6aB
 4uVe9+oTO/DP7awisj6RYpMbzekGf0+UrwxWfnpxM



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Victor Duchovni
On Thu, Dec 08, 2005 at 05:10:20PM -0800, Ed Gerck wrote:

 PGP is public-key email without PKI.

This is true for use in geodesic networks, but not true for
inter-organization email, one ends up introducing gateway systems, that
create an ad-hoc PKI of gateways that have exchanged keys and users
that have authenticated to the gateways when one of the sides has no
such gateway. Key management does not go away.

 So is IBE.

I disagree here, with IBE there still needs a way to securely obtain
the site public key for each site. Granted, you don't need a per-user
key, but this does not make the problem of key management go away.

My *personal* view is that patent encumbered technologies don't have a
major role to play in anything quite as ubiquitous as email.

-- 

 /\ 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: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Anne Lynn Wheeler
Ed Gerck wrote:
 I believe that's what I wrote above. This rather old point (known to the
 X.509 authors, as one can read in their documents) is why X.509 simplifies
 what it provides to the least possible _to_automate_ and puts all the local 
 and
 human-based security decisions in the CPS.
 
 (The fact that the CPS is declared to be out of scope of X.509 is both a
 solution and a BIG problem as I mentioned previously.)

i like the explanation that some attempted to give at the acm sigmod
conference in san jose (circa 1992)  of what was going on in the
x.5xx standards activities; ... a bunch of network engineers trying to
re-invent 1960s database technology ...

the x.509 digital certificates being a stale, static cachable entry of
something in x.500 ldap database ... that was armored for survival in
potentially hostile environment and for relying parties that didn't have
ability to access the real database entry.

cps was something that was needed for trusted third party certification
authority operation ... not for x.509 identity certificate itself. the
issue is when you effectively have these stale, static cacheable,
armored database entries that aren't part of an organization and
business processes that relying parties belong to. traditional access to
database entries (whether you are directly accessing the entry or a
stale, static cached copy of the database entry) ... the business
processes accessing the data and the businesses responsible for the data
are part of the same operation and/or belong to organizations that have
binding contractual relationships.

it is only when you have parties responsible for the information
(trusted third party certification authorities) that are 1) totally
different from the parties relying on the information  and/or 2) the
different parties have no contractual relationships.

one could hypothesize that the creation of CPS were to provide some sort
of substitute for contractual relationship between different
organizations/parties where the relying party has no means of directly
accessing the information and must rely on a stale, static digital
certificate representation (of that information), provided by an
organization that the relying party has no contractual relationship
(just claiming to be a trusted third party certification authority
possibly wasn't enough of a sense of security for some relying parties
and so CPS were invented to provide relying parties a higher sense of
comfort in lieu of having something like an actual contractual
relationship).

that makes CPSs a substitute for contractual relationships when x.509
digital certificates are used for trusted third party certification
authorities where the relying parties and the TTP/CAs are different
organizations.

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Anne Lynn Wheeler
Ed Gerck wrote:
  PGP is public-key email without PKI. So is IBE. And yet neither of
them has
 all the identical, same basic components that PKI also needs. Now, when you
 look at the paper on email security at
 http://email-security.net/papers/pki-pgp-ibe.htm
 you see that the issue of what components PKI needs (or not) is not
 relevant to the analysis.

usually when you are doing baseline ... you start with the simplest,
evaluate that and then incrementally add complexity. in that sense
PGP is much closer to the simplest baseline ... and PKI becomes added
complexity ... inverting you classification; email PKI is PGP with
digital certificates added.

you then could add various layers of public key operation where the
relying parties have direct access to the information in one way or
another and therefor don't require stale, static, armored cached copies
(digital certificate) of the real information.

then you can go thru numerous layers of PKI ... are the relying parties
and the digital certificate creators part of the same business
organizations ... and therefor require neither contractual relationship
and/or CPS as a substitute for contractual relationship.

then add trusted third party certification authority PKI ... where the
relying parties and the certification authorities have direction
contractual relationship and thefore don't require CPS as a substitute
for contractual relationship.

it is when you get to trusted third party certification authority PKI
... where the relying parties and the ttp/ca are part of totally
different business operations and have no contractual relationship that
you then get into the issue of how does a relying party actually know
than it should be trusting a ttp/ca.

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Anne Lynn Wheeler
James A. Donald wrote:
 However, the main point of attack is phishing, when an
 outsider attempts to interpose himself, the man in the
 middle, into an existing relationship between two people
 that know and trust each other. 

in the public key model ... whether it involves pgp, pki, digital
certificates, what-ever; the local user (relying party) has to have a
local trusted repository for public keys. in the pki model, this tends
to be restricted to public keys of certification authorities ... so that
the relying party can verify the digital signature on these
message/document constructs called digital certificates.

in the traditional, ongoing relationship scenario, relying parties
directly record authentication information of the parties they are
dealing with. if a relying party were to directly record the public key
of the people they are communicating with ... it is the trusting of that
public key and the validating of associated public key operations that
provide for the countermeasure for man-in-the-middle attacks and
phishing attacks.

the issue that has been repeatedly discussed is that supposedly the
existing SSL domain name digital certificates was to prevent
impresonation and mitm-attacks. however, because of various
infrastructure shortcomings ... an attacker can still operate with
perfectly valid SSL domain name digital certificates ... and it doesn't
stop the MITM-attack and/or phishing.

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Ed Gerck

Anne  Lynn Wheeler wrote:

usually when you are doing baseline ... you start with the simplest,
evaluate that and then incrementally add complexity. 


I think that's where PKI got it wrong in several parts and not
just the CPS. It started with the simplest (because it was meant to
work for a global RA -- remember X.500?) and then complexity was
added. Today, in the most recent PKIX dialogues, even RFC authors
often disagree on what is meant in the RFCs. Not to mention the
readers.

As another example, at least one IBE offer does not talk about
key lifetime at all -- in fact, the documentation online talks
about using the same key for _all_ future communications. When this,
of course, fails and key expiration is introduced, it will be
over an existing baseline... a patch. Key revocation will be
even harder to introduce in IBE.

As new capabilities conflict with the old, the end result of this
approach seems to ne a lot of patched in complexity and vulnerabilities.

It seems better to start with a performance specification for the full
system. The code can follow the specs as close as possible for
each version, the specs can change too, but at least the grand
picture should exist beforehand. This is what this thread's subject
paper is about, the grand picture for secure email and why aren't
we there yet (Phil's PGP is almost 15 years old) -- what's missing.

BTW, there's a new version out for the X.509 / PKI, PGP, and IBE
Secure Email Technologies paper and Blog comments in the site as well,
at http://email-security.net

Cheers,
Ed Gerck

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-10 Thread Bill Stewart

At 09:40 AM 12/8/2005, Aram Perez wrote:

On Dec 7, 2005, at 10:24 PM, James A. Donald wrote:

Software is cheaper than boats - the poorest man can
afford the strongest encryption, but he cannot afford
the strongest boat.


If it is that cheap, then why are we having this discussion? Why
isn't there a cheap security solution that even my mother can use?


Usability is a hard problem, and security is a really broad field.
PGP, for instance, did a pretty good job of security a decade ago,
given Phil's threat models, (ignoring a few algorithm problems
that were mostly related to trying to skimp on bits
and the subsequent weaknesses in MD5),
but the usability was pretty rough back then,
and version compatibility has gotten enough worse that
Hugh Daniel and I can no longer reliably communicate with PGP.

But even if we both drop back to GPG on text files,
and use remailers run by friends on Tor nodes run by random strangers,
KGB-proof security would require protection against
black-bag jobs on Hugh's keyboards and duping employees
at my company's IT department into weakening my Windows XP configuration.
(For cost-effectiveness and avoidance of detection,
I'd recommend the latter strategy, probably by selling them
some new nifty administration tool or Instant Messaging client :-)

The real security issue for your mother is threat models.
If your mom isn't using a Mac or administering her own Linux box,
then her biggest security threat is that she's computing
on a box made of Swiss cheese (though XP does seem to be
noticeably better than Win95/98/ME) and probably using a browser
that's happy to accept random software installed by spammers
and phishers, and if she's not using webmail,
she's probably running a mail client that happily displays
clickable links to phishing sites purporting to be eBay or her bank.
And that's mostly independent of whether she can trustably
send email to other members of the Ladies' Sewing Circle and
Terrorist Society without the Feds reading it,
which is the kind of problem PGP was trying to solve,
because her bank and eBay don't cryptographically sign their mail.

Popularity of a product is critical to its security;
you don't gain anonymity if the Feds can recognize that
you're one of the dozen users of a given application.
Your mom can use Skype, but nobody she knows uses Crypto Kong,
and I only know a few people who use PGP to email their mom.
But some of the Instant Messaging systems use crypto;
too bad that they're continually trying to be incompatible
with each other to gain market share.


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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-09 Thread Ed Gerck

Anne  Lynn Wheeler wrote:

Ed Gerck wrote:
Regarding PKI, the X.509 idea is not just to automate the process of 
reliance but to do so without introducing vulnerabilities in the 
threat model considered in the CPS.


but that is one of the points of the article that as you automate more 
things you have to be extra careful about introducing new 
vulnerabilities 


I believe that's what I wrote above. This rather old point (known to the X.509
authors, as one can read in their documents) is why X.509 simplifies what it
provides to the least possible _to_automate_ and puts all the local and human-
based security decisions in the CPS.

(The fact that the CPS is declared to be out of scope of X.509 is both a
solution and a BIG problem as I mentioned previously.)

the issue of public key email w/o PKI ... is you have all the identical, 
same basic components that PKI also needs.


PGP is public-key email without PKI. So is IBE. And yet neither of them has
all the identical, same basic components that PKI also needs. Now, when you
look at the paper on email security at
http://email-security.net/papers/pki-pgp-ibe.htm
you see that the issue of what components PKI needs (or not) is not
relevant to the analysis.

 ... as in my oft repeated description of a crook attacking the
authoritative agency that a certification authority uses for the basis 
of its certification, and then getting a perfectly valid certificate.


What you say is not really about X.509 or PKI, it's about the CPS. If the CPS
says it restricts the cert to the assertion that the email address was timely
responsive to a random challenge when the cert was issued, then relying
on anything else (e.g., that the email address is owned or operated by an
honest person or by a person who bears a name similar to that mailbox's 
username)
is unwarranted.

Cheers,
Ed Gerck

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-09 Thread James A. Donald
--
From:   Anne  Lynn Wheeler
[EMAIL PROTECTED]
 PKI is trying to offer some added value in first time
 communication between two strangers

However, the main point of attack is phishing, when an
outsider attempts to interpose himself, the man in the
middle, into an existing relationship between two people
that know and trust each other. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 FYVMooN6NmFglw4lbAf5aNMCV9JMCU/ozMfXJMgI
 4WWQ2pQAOpm3Ttro+Ga5AcJIyW4/gefQzmeVWEsPN


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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-09 Thread James A. Donald
--
James A. Donald:
We can, and should, compare any system with the 
attacks that are made upon it.   As a boat 
should resist every probable storm, and if it 
does not it is a bad boat, an encryption system 
should resist every real threat, and if it does 
not it is a bad encryption system.

Aram Perez
   I'm sorry James, but you can't expect a (several 
   hundred dollar) rowboat to resist the same 
   probable storm as a (million dollar) yacht.

James A. Donald:
  Software is cheaper than boats - the poorest man can 
  afford the strongest encryption, but he cannot 
  afford the strongest boat.

Aram Perez
 If it is that cheap, then why are we having this 
 discussion? Why isn't there a cheap security solution 
 that even my mother can use?

Design is not cheap, and in particular cryptographic 
design is not cheap, because one has to see what attacks 
eventuate - one commonly discovers that one's
cryptography was fine, but one's threat model was
inadequate.  But having been designed, and survived 
attack, it can then be supplied to everyone. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 J0TlTGnN72O7gpg1XX5GRDTi4nJ4wVeAa557yccN
 44MC72QwGhBFeTainKp+spi3G6oGpfuNsPZYDSpwt



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-09 Thread Matthew Byng-Maddick
On Thu, Dec 08, 2005 at 09:40:22AM -0800, Aram Perez wrote:
 On Dec 7, 2005, at 10:24 PM, James A. Donald wrote:
 Aram Perez
 James A. Donald:
 We can, and should, compare any system with the
 attacks that are made upon it.   As a boat should
 resist every probable storm, and if it does not it
 is a bad boat, an encryption system should resist
 every real threat, and if it does not it is a bad
 encryption system.
 I'm sorry James, but you can't expect a (several
 hundred dollar) rowboat to resist the same probable
 storm as a (million dollar) yacht.
 Software is cheaper than boats - the poorest man can
 afford the strongest encryption, but he cannot afford
 the strongest boat.
 If it is that cheap, then why are we having this discussion? Why  
 isn't there a cheap security solution that even my mother can use?

Can your mother sail a boat? Worth noting that more expensive doesn't
necessarily make the boat easier to sail (in fact there are more things
to tune, in general), and at the point that you're getting a million
pound yacht, you'll probably be hiring someone very qualified to skipper
it for you... Is that a useful comparison then to security software? I
would expect a competent sailor to be able to weather some storms in a
rowboat, where, your mother (to use the example above) would fail. If
we carry the discussion to its logical conclusion: I'd therefore expect
someone who understands about security to be able to use available
security software with a reasonable ability to keep their data safe.

Useability and cost are not necessarily related. This discussion
is conflating both things. In the security software case, the
useability is not there yet at all, the cost is generally fine.

The question you want to be asking is what can be done to make the
available software useable safely by my mother?

Cheers

MBM

-- 
Matthew Byng-Maddick  [EMAIL PROTECTED]   http://colondot.net/
  (Please use this address to reply)

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread Anne Lynn Wheeler
Ed Gerck wrote:
  Depends on your use. An X.509 identity cert or a PGP cert
 can be made as secure as you wish to pay for. The real
 question, however, that is addressed by the paper is
 how useful are they in terms of email security? How do
 you compare them and which one or which product to choose
 from? What are the trade-offs?

i've periodically written on security proportional to risk ... small sample
http://www.garlic.com/~lynn/2001h.html#61

then the issue is what security are you interested in and what are the
threat models and corresponding countermeasures.

in the security pain model

P .. privacy
A .. authentication
I .. integrity
N .. non-repudiation

you may need authentication and integrity (say from digital signature)
but not necessarily privacy/confidentiality.

in normal ongoing email, there is a lot of repeated stuff and/or
out-of-band stuff ... that makes certificates redundant and superfluous
... they are targeted at the letters of credit/introduction paradigm
from the sailing ship days. certificates basically are representations
of some certifying process performed by a certification authority. the
integrity and security of the certificate itself may have absolutely
nothing to do with the integrity and security of the certification
business process ... minor drift in sci.crypt
http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question

furthermore, the whole complexity and series of processes involved in a
PKI-based infrastructure may have the certificates themselves totally
redundant and superfluous because the recipient has numerous other
indicators that they know who it is that they are dealing with. the
introductioin of PKI and certificates in such an environment may
actually create greater vulnerabilities ... since it may convince the
recipient to trust the PKI operation more than they trust their own,
direct knowledge ... and the PKI operation opens up more avenues of
compromise for the attackers.

... there is even a slightly related article that i ran across yesterday:

An Invitation to Steal; The more you automate your critical business
processes, the more vigilant you need to be about protecting against
fraud
http://www.cio.com.au/index.php/id;1031341633;fp;4;fpid;18

.

the other issue in digital signature based operation is that it is a
part of 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

where the fundamental linchpin for the whole operation is the protection
and confidentiality of the private key. unfortuantely almost all digital
signature operations tend to talk about the integrity and security of
the PKI operation and its certificates ... when they should be talking
about the integrity and security of the private keys and the
integrity and security of the digital signing environment.

i've sporadically gone so far as to assert that the focus on the
integrity and security of PKI and certificates results in obfuscating
the fundamental integrity and security issues with private keys and
digital signing environments (aka long before anybody is talking about
the integrity of the certificates ... they should have resolved that the
private keys are only available in hardware tokens of known and specific
integrity characteristics).

The whole PKI and certificate operation having a design point of
resolving first time interaction between complete strangers (as in the
letters of credit/introduction paradigm from sailing ship days) and
should come after the basic underlying infrastructure isssues involving
trusted communication between two entities has first been resolved
(whether it is first time communication between complete strangers or
not ... which then can be layered on top of a sound infrastructure that
has its fundamental operations already resolved).

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread James A. Donald
--
James A. Donald:
  We can, and should, compare any system with the
  attacks that are made upon it.   As a boat should
  resist every probable storm, and if it does not it
  is a bad boat, an encryption system should resist
  every real threat, and if it does not it is a bad
  encryption system.

Aram Perez
 I'm sorry James, but you can't expect a (several
 hundred dollar) rowboat to resist the same probable
 storm as a (million dollar) yacht.

Software is cheaper than boats - the poorest man can
afford the strongest encryption, but he cannot afford
the strongest boat.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 /RDdl4GaftLppriBOAhXkSmzUWuV9JdpELHaG+Yq
 4IZIPBnHPpNQYioKOhKdPdh6q6NwgwGDlLnbikvmA


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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread StealthMonger
James A. Donald [EMAIL PROTECTED] writes:

 ...  email should be sent by a direct connection from the client to
 the recipient mail server, rather than this store and forward crap.

This would eliminate the only available technique for strong anonymity
or pseudonymity.  Strong anonymity or pseudonymity cannot be achieved
if there is a direct connection from the sender to the recipient
because it can be traced.  For strong anonymity or pseudonymity, the
only available secure technology is anonymizing remailers with random
latency store and forward.

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread James A. Donald
--
From:   Ed Gerck [EMAIL PROTECTED]
 Depends on your use. An X.509 identity cert or a PGP 
 cert can be made as secure as you wish to pay for.

Many users are already using MUAs that check signatures.
Why are phishing targets not already using signed mail? 

I conjecture that this is because true names don't really address the 
issue of true relationships.  Does anyone have any market research 
information as to why phishing targets generally send out plain mail?

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 CMjwBMx17XqegWEl4z+ZLdfTB+wFlQKrdm1516HH
 4/HqDwhTaKRygswyOmR+oP41kfEhib7KJwyxDDq3p



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread Ed Gerck

Anne  Lynn Wheeler wrote:

i've periodically written on security proportional to risk ... small sample
http://www.garlic.com/~lynn/2001h.html#61

...
introductioin of PKI and certificates in such an environment may
actually create greater vulnerabilities ... since it may convince the
recipient to trust the PKI operation more than they trust their own,
direct knowledge ... and the PKI operation opens up more avenues of
compromise for the attackers.


Regarding PKI, the X.509 idea is not just to automate the process of reliance
but to do so without introducing vulnerabilities in the threat model considered
in the CPS.

What's a bit of a struggle, still, is that many people do not fully realize
that the CPS is outside the scope of PKI. This is both a solution (makes the
X.509 effort independent of local needs) and a big problem, as CAs (writers
of the CPS) have the power to write almost anything they want, including
their notorious DISCLAIMER (where _near_ everything of value to the subscriber
is disclaimed, while _everything_ of value to the user is disclaimed).

That's why its useful to compare X.509 / PKI, PGP, and IBE technologies
for secure email, to know what are the trade-offs.

By comparing the capabilities and faults of the secure email products
per technology used, these and other problems come up in the score card.

Cheers,
Ed Gerck

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-08 Thread Anne Lynn Wheeler

Ed Gerck wrote:
Regarding PKI, the X.509 idea is not just to automate the process of 
reliance but to do so without introducing vulnerabilities in the threat model 
considered in the CPS.


but that is one of the points of the article that as you automate more 
things you have to be extra careful about introducing new 
vulnerabilities (of course a business operation will make claims that 
while they may have introduced enormous additional complexity and number 
of business processes ... that they are all perfect and have no 
vulnerabilities).


the issue of public key email w/o PKI ... is you have all the identical, 
same basic components that PKI also needs.


there is a local trusted public key repository and a method of getting 
keys into/out of that trusted public key repository. in the non-PKI 
case, the trusted public key repository contains public keys that are 
used to directly authenticate messages from other entities. in the PKI 
case, the trusted public key repository also contains public keys that 
are used to authenticate messages from a certification authority; these 
messages are called digital certificates. the digital certificates, in 
turn contain other public keys that can be used in authenticating 
messages from directly communicating entities.


the original PKI and digital ceritificate design point is the letters of 
credit/introduction (from the sailing ship days) ... addressing first 
time communication between two strangers.


that a large volume of email doesn't involved first time communication 
between two strangers that have no prior relationship ... and so one 
possible question is does a PKI operation ... does the little or no 
added value for such communication possibly offset the drastically 
increased amount of complexity and increased number of business 
processes (that also contribute to possible enormous increase in 
potential for vulnerabilities).


PKI is trying to offer some added value in first time communication 
between two strangers (say the bulk mailing advertising industry) ... 
and it is possibly acceptable the significant increase in business 
processes and complexity is justified in improving reliance in the bulk 
mailing advertising market segment. The question does the vast increase 
in business processes and complexity (with the possibility that the 
increased business processes and complexity also introduce significant 
new types of vulnerabilities) justify its use in the scenarios where 
first time communication between two strangers is not involved.


This is business process analysis of what goes on in a basic public key 
email operation ... aka all the public key operations and the entity's 
trusted public key repository ... and then showing where PKI 
incrementally adds business processes and complexity to that basic 
infrastructure  certification authority public keys added to the 
trusted public key repository, these new kind of messages called digital 
certificates and the indirection between the certification authority's 
public key (in the entity's trusted public key repository) and the 
public key of the other entities communicated with.


The additional digital certificate verification technical steps that a 
PKI operation adds to a core fundamental public key email process (that 
directly has access to public keys of entities directly communicated 
with) ... also drags in the enormous amount of complexity and additional 
business processes that the certification authorities have to perform.


It is some of this other complexity and business processes that may be 
attacked ... as in my oft repeated description of a crook attacking the 
authoritative agency that a certification authority uses for the basis 
of its certification, and then getting a perfectly valid certificate.
The user (relying-party) then may have a perfectly valid public key for 
an entity that they've communicated with for years  but this 
perfectly valid certificate (from a crook) now claims that the user must 
now automatically accept the crook's public key also as representing the 
same entity.


so a traditional risk/threat analysis ... would frequently analyze the 
basic components ... establish a baseline threat/vulnerability profile 
... and then consider what happens when additional complexity does to 
the baseline. I assert that a simple public key email operation can 
establish a baseline w/o any digital certificates ... and then you 
consider what happens when the baseline has digital certificates added
(which then also drags in all the business process vulnerabilities that 
may exist at the certification authority ... and all dependencies that 
tthe certification authority has). we had to sort of look at this sort 
of stuff when we were asked to work with this small client/server 
startup that wanted to do payment transactions on their server

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and we had to go 

Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-07 Thread James A. Donald
--
From:   Ed Gerck [EMAIL PROTECTED]  
Subject:X.509 / PKI, PGP, and IBE Secure 
Email Technologies

 http://email-security.net/papers/pki-pgp-ibe.htm

 X.509 / PKI (Public-Key Infrastructure), PGP (Pretty 
 Good Privacy) and IBE (Identity-Based Encryption) 
 promise privacy and security for email. But comparing 
 these systems has been like comparing apples with  
 speedboats and wingbats. A speedboat is a bad apple, 
 and so on.

We can, and should, compare any system with the attacks 
that are made upon it.   As a boat should resist every 
probable storm, and if it does not it is a bad boat, an 
encryption system should resist every real threat, and 
if it does not it is a bad encryption system.   And no 
blaming the users.  An encryption system must 
accommodate the user, not the user the system.

Problem 1:  The primary weakness of existent email is 
its vulnerability to after the fact investigations.

Problem 2: The secondary weakness is ease of forgery. So
far spammers are not making much effort to forge their
way through your white lists, but phishers are forging
the identities of organization's with which you are
likely to have relationships.

Most efforts have been directed at problem 2, but the 
true names approach as failed for web sites, and it is 
too burdensome for people even to try for email

The user interface has to be a web page button Please 
click here to us to send, and you to whitelist, our 
emails about blah blahUser clicks.  Browser Chrome 
pops up.   Will you white list emails signed by public 
key YJQwlHzIzHP7nm04t3CFcrjFlMY, apparently 
controlled by website www.bankofadelaide.com, common 
name Bank of Adelaide, current favorite name
/favorites/banks/Bank of Adelaide - Home - Personal,
proposed petname banks/Bank of Adelaide - Home -
Personal

The spam filter has to pop up THE EXACT SAME BROWER 
CHROME, when the user tells it to whitelist a signed 
email that has been wrongly spam filtered.

Crap with certificate authorities or web of trust just 
is not flying, and is not going to fly.

But, of course, the really serious attack is problem 1, 
the problem that there are too damn many copies of email 
floating around, due to sending it in the clear and the 
store and forward architecture, which has got lots of 
people into really deep trouble.

The only copies should be those that the sender, and the 
receiver, choose to keep, and they should be encrypted 
with the user's email passphrase, the user's email 
passphrase should be known only to the client, not to 
the server, and the user's passphrase should have all 
the usual strengthening to minimize the effectiveness of
offline dictionary attack.  To limit the number of
possible copies, email should be sent by a direct
connection from the client to the recipient mail server,
rather than this store and forward crap.

Of course this is not email as we know it.  It is a new 
and wholly incompatible protocol, which can be 
transparently gatewayed to email as we know it.  

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 EHhbMLsVYHKM99sSClQYV0/o/XVA5PN4UrXpsU0v
 4ca9QRhhmxSqwOK6ef12X8jbDKTR/AMD0r8RQzn9j



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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-07 Thread Aram Perez

On Dec 7, 2005, at 8:40 AM, James A. Donald wrote:


--
From:   Ed Gerck [EMAIL PROTECTED]
Subject:X.509 / PKI, PGP, and IBE Secure
Email Technologies


http://email-security.net/papers/pki-pgp-ibe.htm

X.509 / PKI (Public-Key Infrastructure), PGP (Pretty
Good Privacy) and IBE (Identity-Based Encryption)
promise privacy and security for email. But comparing
these systems has been like comparing apples with
speedboats and wingbats. A speedboat is a bad apple,
and so on.


We can, and should, compare any system with the attacks
that are made upon it.   As a boat should resist every
probable storm, and if it does not it is a bad boat, an
encryption system should resist every real threat, and
if it does not it is a bad encryption system.


I'm sorry James, but you can't expect a (several hundred dollar)  
rowboat to resist the same probable storm as a (million dollar)  
yacht. There is no such thing as one-size encryption system fits all  
cases.


Regards,
Aram Perez

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


Re: X.509 / PKI, PGP, and IBE Secure Email Technologies

2005-12-07 Thread Anne Lynn Wheeler
Aram Perez wrote:
 I'm sorry James, but you can't expect a (several hundred dollar) 
 rowboat to resist the same probable storm as a (million dollar)  yacht.
 There is no such thing as one-size encryption system fits all  cases.

unfortunately there are more than a few counter-examples that are made
enormously complex (and extremely expensive) and it turns out that the
complexity itself introduces additional failure and threat
vulnerabilities which aren't found in KISS-solutions.

nearly ten years ago, i joked that i was going to take a $500 milspec
part, cost reduce it by two orders of magnitude and at the same time
improve its security (in part by eliminating unnecessary features that
contributed to security vulnerabilities).

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