Andrew,
You make some good points. The purpose of the paper is to show
where and what the problems are -- and motivate solutions.
The points you note are not technology limitations of usability
but implementation problems. Also, in business use, clients can
be chosen among those that work and the proper infrastructure
provided. The usage difficulty ("I can't even use it") exists
mostly for open-ended Internet use. Of course, we still have all the
other difficulties pointed out in the paper
Regards,
Ed Gerck
--- Andrew Patrick wrote:
> Hi;
>
> I have not read your paper in detail, but thought I
> would mentioned problems that I have had in using
> X.509 based email signatures.
>
> It boils down to the fact that email messages signed
> with X.509 certificates break a number of message
> clients at the receiving end to the point that I have
> given up on signing my email.
>
> Some clients simply fail to display the signed
> messages (usually webmail systems).
>
> Other clients assume that a message received with a
> signature must be replied to in a signed fashion, and then
> break when the replier does not have a certificate
> configured (MS Outlook Express).
>
> Some mail clients alter the incoming message (i.e., to insert
> ads, ala Yahoo mail), so a message integrity check fails, and
> some usually cryptic error mesage is shown to the receiver.
>
> So, in my mind secure email systems suffer from the
> most sever usability problem -- they don't work.
Welcome to Email-Security. This is a technical development forum dedicated to a fresh exploration of the Internet email security issues of today, with website at http://email-security.net. Comments and paper contributions on the theme of email security are welcome. Papers will be peer-reviewed before publication. Product and service listings are also welcome, see website.
Wednesday, December 21, 2005
Saturday, December 17, 2005
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
James A. Donald wrote:
James (and Travis, re previous posting on PGP trust model),
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
From: Werner KochYou 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 (and Travis, re previous posting on PGP trust model),
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
Thursday, December 15, 2005
Re: about secure email technologies
--- Dino Esposito wrote:
> Mr. Gerck
> I skimmed through your "comparison of secure email
> techs..." and it
> seems to me that some of the desirable features and
> problems are outside
> the scope of the proposed technics (PKI, PGP, IBE).
> I mean, they are
> requirements about the mail protocols (e.g. return
> receipt) or SSL
> (Server spoofing).
The secure email technology may be able to directly
include a feature, in which case there's a check mark.
If the feature can't be included, an additional protocol
may be used to provide it. For example, server spoofing
could be prevented in IBE, directly, when the user
connects to the PKG to get the key (prventing credential
compromise for the real PKG).
> My field is PKI, and I think PKI
> (perhaps PGP too)
> can supply some basic technologies in order to build
> a "Secure email
> system", but it's unable to supply the full
> solution.
which must, most importantly, be usable. That's why
the paper can be useful to both improve PKI (what's
missing?) and to provide a view to new technologies
that can overcome current limitations.
> In Italy we have set up a quite complex legal and
> technical framework in
> order to have a "registered email" with all the
> features of the
> traditional registered mail and some plus (not only
> the sending is
> certified, but also the content and the integrity of
> the messages). This
> framework rules the single message AND the mail
> service providers, that
> have to be accreditated as the most trusted
> Certification Service Provider.
> These rules do not address confidentiality (SSL is
> mandatory, but the
> accreditated mail servers are nevertheless able to
> read any message),
> but this is probably the simplest issue since
> encrypting the body of a
> message is quite easy
But decryption is not, as the private-key must
be protected. That's where it's more difficult.
> I'm going to summarize these rules in English for
> other purposes; if you
> are interested I can send you as soon as available.
Yes, please do!
> Finally, I think that "F17 Verified Timestamp" is a
> feature supplied by
> PKI: the timestamp token as defined by the RFC3161
Yes, it is. It's now added in the table.
Ciao,
Ed Gerck
Re: Comparison of X.509 / PKI, PGP, and IBE
- Michael Ströder wrote:
> Ed,
>
> you've asked for feedback on
> http://email-security.net/papers/pki-pgp-ibe.htm.
>
> "1. DESIRABLE FEATURES REFERENCE SHEET"
> I don't understand F18 and F19. Maybe you're
> referencing transparent
> encrypting of e-mail attachments? But then this
> should not be limited to
> HTML attachments.
Yes, you're right. It has been improved in the new
version at
http://email-security.net/papers/pki-pgp-ibe.htm
> Personally I'd never use a e-mail software which
> follows this requirement:
> "(**) [..] If the recipient wishes to decline to
> provide the receipt,
> the recipient should not attempt to decrypt the
> message."
This is the same rule that postal mail follows. The
receipt is useful for both sender and recipient, in
addition as evidence for the sender; for example, if
the sender knows that the recipient read (decrypted)
the email, the sender does not have to send another
email or make a call.
> "2. PROBLEMS / ATTACKS REFERENCE SHEET"
> P1 to P5 seems to be very much related to
> client-server processing. Are
> you pointing to web-based e-mail clients here? If
> yes, I'd suggest to
> make this more clear in the text by explicitly
> mentioning this type of
> service.
They apply to desktop-, intranet- or web- based. For
example P15 applies to PGP, web based or not.
> It's not clear to me why you list "F6 Base 64
> Encoding" as a feature.
It looks like a lame feature but some email products
do it better than others. For product evaluation you
can change the check mark to a product-specific grade.
Cheers,
Ed Gerck
Tuesday, December 13, 2005
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
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.
--
Travis H.
Monday, December 12, 2005
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
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
payments. if data breaches and evedsdropping no longer can result in
fraudulent transactions, then there is much less reason for
sophisticated countermeasures for those threat/vulnerabilities (ssl is
no longer needed to prevent evesdropping on the account number, since
evesdropping on the account number no longer provides any practical
fraudulent benefit).
simple public key registration as part of financial account operation
(in an onging relationship that a consumer has with their financial
institution) not only is a certificateless digital signature model
http://www.garlic.com/~lynn/subpubkey.html#certless
but also eliminates much of the requirement for existing major use of
digital certificates; that of providing ssl encrypted communication
http://www.garlic.com/~lynn/subpubkey.html#sslcert
as countermeasure for evesdropping for the purpose of account number
havesting
http://www.garlic.com/~lynn/subpubkey.html#harvest
furthermore, not only does simple x9.59 digital signature authenticated
transactions eliminate the threat/vulnerability of evesdropping for
account number harvesting, but it also eliminates the
threat/vulnerability of data breaches for account number harvesting
aka the harvesting could still go on, but the threat/vulnerability of
fraudulent transactions as a consequence of harvesting is eliminated ...
note that phishing attacks for the purpose of account number harvesting
is also eliminated as a threat/vulnerability ... phishing can still go
on, account numbers cna still be harvested, the account numbers are
useable for fraudulent transactions w/o the digital signature.
misc. past posts mentioned bi-model transaction distribution and/or
having suggested employee fbi background checks as part of merchant
certification process.
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption
Empower These Terrorists?
http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean
Anything?
Anne & Lynn Wheeler
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
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 wrote:
> 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
James A. Donald
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
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
Friday, December 09, 2005
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Simon McMahon wrote:
Thanks!
You make a good point -- if encryption is made simpler and more people
use it, it will be attacked. Reader "dgustafson1" (see blog at
http://email-security.blogspot.com/2005/12/re-x509-pki-pgp-and-ibe-se_113408257591787133.html)
also comments on not to be forced to spend time handling mass quantities
of unwanted secure messages (e.g., encrypted spam). Providing an
additional signature to be verified before decryption could help,
as you point out for S/MIME.
The paper does take this problem into account, but it does so in a
technologically-neutral way, using F10 (Meets Digital Signature
Requirement), F11 (Authenticates Sender and Recipient) and absence of
several P#'s especially P6 (Unverified Sender's Email Address). Please
check the blog (entry above) for my comments on this.
P6 is important here because if you can trace the sender (there's no
spoofed sender email address), not only the sender becomes liable
but you have now a fixed, verified target to accept or block beforehand.
But even with HSM, root operators can do a lot to undermine user security,
including reading email. Banks routinely separate development from
operation, even with HSM, so that operation personnel do not become aware
of vulnerabilities. Another example is the "no loner" policy for handling
sensitive data, even with HSM.
Not only conflicting business interests are of concern here but also
unnoticed data mining, blackmail, disclosing trade secrets and many other
activities (even legal) that break user's privacy, HSM or not, to benefit
someone. The market knows this, as we could see in the rejection of MS
Passport, proposing to hold data of other businesses' users in secure
storage at Microsoft.
That's why the lists of features and problems / attacks in the paper have
several items to protect user's privacy. What's the point of email
encryption if the supposed secure channel is actually open (even if just
to one eavesdropper)? It may be even worse than no encryption at all,
because there'd be a presumption of confidentiality by the communicating
parties.
IBE has that capability by construction. Some papers suggest that the
effects can be constrained if the IBE reduces each key's usage to a few
or even to one message. However, even if the security parameters for the
IBE change for every user's key (which would be a huge burden for all
recipients and senders) a simple data logging device at the Private
Key Server (and/or at the recipient's end) could log all keys and allow
any message to be read.
Of course, a country's laws may require key escrow or key discovery.
And businesses, to prevent problems if the proverbial bus hits an
employee, may also require key escrow (and that's why a biometrical
access system requires a backdoor, which is yet another problem).
However, providing key escrow without a choice, for everyone, might
create more problems, for example if the watchers become targets
themselves.
The key escrow debate was very active in the 90's. More problems than
benefits. Law enforcement can break and use communication information
(ie, routing, IP numbers, time, frequency of use, etc.) much more
easily than message information, and use it more effectively too. People
can always use a simple one-time code book or jargon to defeat any key
escrow scheme. The secret channel created by the code-talkers in WWII
was, reportedly, never broken.
Some do, by enforcing a security policy -- e.g., "email to boss@home.com
must be sent encrypted". Receiving securely can also be defined by the
sender; if I sent it encrypted, you have no choice.
Yes, and that's why I did not include it in the paper.
Thanks for the good comments!
Ed Gerck
Nice paper! I especially liked the cited 'Johnny' paper.
Thanks!
What about denial of service attacks where super large RSA keys are
used or faked which either crash or tie up the server with decryption
and verification of bogus messages. Even a flood of normal
encrypted/signed messages have to be decrypted before the signature can
be checked. I've seen some messaging systems where the client encrypts
first, then signs (opposite of smime) to avoid decrypting invalid
messages on the server.
You make a good point -- if encryption is made simpler and more people
use it, it will be attacked. Reader "dgustafson1" (see blog at
http://email-security.blogspot.com/2005/12/re-x509-pki-pgp-and-ibe-se_113408257591787133.html)
also comments on not to be forced to spend time handling mass quantities
of unwanted secure messages (e.g., encrypted spam). Providing an
additional signature to be verified before decryption could help,
as you point out for S/MIME.
The paper does take this problem into account, but it does so in a
technologically-neutral way, using F10 (Meets Digital Signature
Requirement), F11 (Authenticates Sender and Recipient) and absence of
several P#'s especially P6 (Unverified Sender's Email Address). Please
check the blog (entry above) for my comments on this.
P6 is important here because if you can trace the sender (there's no
spoofed sender email address), not only the sender becomes liable
but you have now a fixed, verified target to accept or block beforehand.
I used to work with HSMs (hardware crypto & key storage) and we used to
get many requests for accelerated crypto and strong key storage.
Standard interfaces to crypto subsystem was the feature we required.
Some corporate users can justify the cost of this feature.
But even with HSM, root operators can do a lot to undermine user security,
including reading email. Banks routinely separate development from
operation, even with HSM, so that operation personnel do not become aware
of vulnerabilities. Another example is the "no loner" policy for handling
sensitive data, even with HSM.
Not only conflicting business interests are of concern here but also
unnoticed data mining, blackmail, disclosing trade secrets and many other
activities (even legal) that break user's privacy, HSM or not, to benefit
someone. The market knows this, as we could see in the rejection of MS
Passport, proposing to hold data of other businesses' users in secure
storage at Microsoft.
That's why the lists of features and problems / attacks in the paper have
several items to protect user's privacy. What's the point of email
encryption if the supposed secure channel is actually open (even if just
to one eavesdropper)? It may be even worse than no encryption at all,
because there'd be a presumption of confidentiality by the communicating
parties.
Key-escrow (encryption key only) allows content filtering and law
enforcement agencies to function. Sounds like IBE has that capability.
IBE has that capability by construction. Some papers suggest that the
effects can be constrained if the IBE reduces each key's usage to a few
or even to one message. However, even if the security parameters for the
IBE change for every user's key (which would be a huge burden for all
recipients and senders) a simple data logging device at the Private
Key Server (and/or at the recipient's end) could log all keys and allow
any message to be read.
Of course, a country's laws may require key escrow or key discovery.
And businesses, to prevent problems if the proverbial bus hits an
employee, may also require key escrow (and that's why a biometrical
access system requires a backdoor, which is yet another problem).
However, providing key escrow without a choice, for everyone, might
create more problems, for example if the watchers become targets
themselves.
The key escrow debate was very active in the 90's. More problems than
benefits. Law enforcement can break and use communication information
(ie, routing, IP numbers, time, frequency of use, etc.) much more
easily than message information, and use it more effectively too. People
can always use a simple one-time code book or jargon to defeat any key
escrow scheme. The secret channel created by the code-talkers in WWII
was, reportedly, never broken.
Also, these email systems are only discretionary - the user has to
choose to send / receive securely. None of them (afaik) support
mandatory security where the security is always on and cant be
disabled or ignored by the user.
Some do, by enforcing a security policy -- e.g., "email to boss@home.com
must be sent encrypted". Receiving securely can also be defined by the
sender; if I sent it encrypted, you have no choice.
At least with some clients they can be set to
default to secure which is a bit better. I guess that is a feature of
the email client regardless of the crypto technology though.
Yes, and that's why I did not include it in the paper.
Thanks for the good comments!
Ed Gerck
Thursday, December 08, 2005
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler 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. Further, 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.
For example, let's see an oft repeated issue 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".
This is not really about X.509 or PKI, it's about the CPS. If the CPS
says it restricts cert reliance to the assertion that the subscriber's
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, or even by a person at all) is
unwarranted. With this CPS, there was really no "attack" on the CA and the
cert _is_ perfectly valid -- all it does is authenticate the email address
that _was_ verified.
What's a bit of a struggle, thus, is that many subscribers and relying-
parties do not fully realize that the CPS is outside the scope of PKI and
yet defines the email security model for that PKI -- what you can trust
and what you can't. Yes, in this regard, there are as many PKIs as there
are CAs and this is reflected in the paper as problem P16 (Requires Common
Root Of Trust).
Having the CPS outside the scope of X.509/PKI 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 relying-
party 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
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. Further, 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.
For example, let's see an oft repeated issue 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".
This is not really about X.509 or PKI, it's about the CPS. If the CPS
says it restricts cert reliance to the assertion that the subscriber's
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, or even by a person at all) is
unwarranted. With this CPS, there was really no "attack" on the CA and the
cert _is_ perfectly valid -- all it does is authenticate the email address
that _was_ verified.
What's a bit of a struggle, thus, is that many subscribers and relying-
parties do not fully realize that the CPS is outside the scope of PKI and
yet defines the email security model for that PKI -- what you can trust
and what you can't. Yes, in this regard, there are as many PKIs as there
are CAs and this is reflected in the paper as problem P16 (Requires Common
Root Of Trust).
Having the CPS outside the scope of X.509/PKI 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 relying-
party 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
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
dgustafson1 wrote:
>
> Hi Ed,
>
> Things that are interesting that may not be in your charts:
Thanks for the good points. My comments are inlined.
> Fx = Secure Message Exchange Negotiation
> ----------------------------------------
> Ideally, if a correspondent's email address is known, it should be easy
> to start the exchange of secure messages with that correspondent. It
> should be possible to query the entity's email address for any
> information necessary to initiate exchange of secure message(s). Intent
> is to _not_ require a single, world-readable directory of all potential
> email correspondents and their current email address(es), etc. -- the
> existence of which would likely have disastrous consequences.
The lack of this feature is what problems P13 (Must Pre-Enroll Recipients)
and P16 (Must Send Own Certificate) are about. I preferred to list the problems
rather than the feature because it explains the two parts of the issue, is more
concise and is technologically-neutral. Describing the feature (as above) would
require a longer text, and talking about a directory (for example).
In other words, if the secure email system does NOT have problems P13 and P16,
there is no need to talk about Fx.
> F(x+1) = Secure Message Exchange Recipient Privacy
> --------------------------------------------------
> Conversely, it should be possible for each correspondent to exert their
> personally desired level of control over just who is able to access to
> his/her email address and, particularly, the corresponding security
> profile. Perhaps analagous to Caller-ID, the individual user
> (recipient) can determine which queries receive valid security
> information and which are handled in some other way. Intent is to allow
> desired message exchange but not be forced to spend time handling (mass
> quantities of) unwanted secure messages.
If there is no need to grant access to "valid security information" to the
sender (because P13 and P16 do not exist), then F(x+1) is not needed to protect
the recipient's privacy.
However, you still make another good point: the recipient should not be
forced to spend time handling (mass quantities of) unwanted secure messages.
Which may be even worse if anyone can easily send you a secure message
(because P13 does not exist).
This problem (i.e, allowing the recipient to determine which secure
message to decrypt) is handled by a combination of F8 (Identity
Certificate) viewed before decryption, F10 (Meets Digital Signature Requirement)
to make sure the message is not spoofed even though it is signed, F11 (Authenticates
Sender and Recipient) to make sure the sender is not spoofing a valid credential,
with absence of several P#'s especially P6 (Unverified Sender's Email Address).
P6 is important here because if you can trace the sender (there's no spoofed
sender email address), not only the sender becomes liable but you have now
a fixed, verified target to accept or block.
> F(x+2) = Secure Message Exchange Blocking
> -----------------------------------------
> Ability to "undo" an earlier decision to engage in secure message
> exchange with a particular correspondent or group of correspondents. I
> want to "revoke" my credential specifically with respect to future use
> for communication with certain other correspondent(s).
F(x+2) is not needed for the reasons above -- those correspondents do not
need to access security information from you and you can easily block them.
> Obvously, I don't have a specific solution in mind and have not tried to
> separate these capabilities cleanly. They'll all kind of run together
> at first. Also, I don't care whether public key, secret key, DH key
> exchange, x.509 certificates, or (any other crypto technology) is used
> in any solution.
Yes, that's why the paper uses features and attacks/problems that are
technologically neutral and uses them to create a technologically-neutral
score card, that is also product-agnostic.
> The main point, at the outset, is to define a compellingly service that
> has sufficient benefits to drive the efforts necessary to achieve it's
> development (i.e., as opposed to allocating resources on other
> activities). All of us have been waiting for at least 10 years to start
> using secure email (i.e., as we know it today). A decade of collective
> experience strongly suggests there must be some new thinking before
> things will be able to move ahead.
Yes. The work provides a view to both improve the email security technologies
X.509 / PKI, PGP and IBE, and develop the specifications for new technology
beyond current limitations.
Cheers,
Ed Gerck
>
> Hi Ed,
>
> Things that are interesting that may not be in your charts:
Thanks for the good points. My comments are inlined.
> Fx = Secure Message Exchange Negotiation
> ----------------------------------------
> Ideally, if a correspondent's email address is known, it should be easy
> to start the exchange of secure messages with that correspondent. It
> should be possible to query the entity's email address for any
> information necessary to initiate exchange of secure message(s). Intent
> is to _not_ require a single, world-readable directory of all potential
> email correspondents and their current email address(es), etc. -- the
> existence of which would likely have disastrous consequences.
The lack of this feature is what problems P13 (Must Pre-Enroll Recipients)
and P16 (Must Send Own Certificate) are about. I preferred to list the problems
rather than the feature because it explains the two parts of the issue, is more
concise and is technologically-neutral. Describing the feature (as above) would
require a longer text, and talking about a directory (for example).
In other words, if the secure email system does NOT have problems P13 and P16,
there is no need to talk about Fx.
> F(x+1) = Secure Message Exchange Recipient Privacy
> --------------------------------------------------
> Conversely, it should be possible for each correspondent to exert their
> personally desired level of control over just who is able to access to
> his/her email address and, particularly, the corresponding security
> profile. Perhaps analagous to Caller-ID, the individual user
> (recipient) can determine which queries receive valid security
> information and which are handled in some other way. Intent is to allow
> desired message exchange but not be forced to spend time handling (mass
> quantities of) unwanted secure messages.
If there is no need to grant access to "valid security information" to the
sender (because P13 and P16 do not exist), then F(x+1) is not needed to protect
the recipient's privacy.
However, you still make another good point: the recipient should not be
forced to spend time handling (mass quantities of) unwanted secure messages.
Which may be even worse if anyone can easily send you a secure message
(because P13 does not exist).
This problem (i.e, allowing the recipient to determine which secure
message to decrypt) is handled by a combination of F8 (Identity
Certificate) viewed before decryption, F10 (Meets Digital Signature Requirement)
to make sure the message is not spoofed even though it is signed, F11 (Authenticates
Sender and Recipient) to make sure the sender is not spoofing a valid credential,
with absence of several P#'s especially P6 (Unverified Sender's Email Address).
P6 is important here because if you can trace the sender (there's no spoofed
sender email address), not only the sender becomes liable but you have now
a fixed, verified target to accept or block.
> F(x+2) = Secure Message Exchange Blocking
> -----------------------------------------
> Ability to "undo" an earlier decision to engage in secure message
> exchange with a particular correspondent or group of correspondents. I
> want to "revoke" my credential specifically with respect to future use
> for communication with certain other correspondent(s).
F(x+2) is not needed for the reasons above -- those correspondents do not
need to access security information from you and you can easily block them.
> Obvously, I don't have a specific solution in mind and have not tried to
> separate these capabilities cleanly. They'll all kind of run together
> at first. Also, I don't care whether public key, secret key, DH key
> exchange, x.509 certificates, or (any other crypto technology) is used
> in any solution.
Yes, that's why the paper uses features and attacks/problems that are
technologically neutral and uses them to create a technologically-neutral
score card, that is also product-agnostic.
> The main point, at the outset, is to define a compellingly service that
> has sufficient benefits to drive the efforts necessary to achieve it's
> development (i.e., as opposed to allocating resources on other
> activities). All of us have been waiting for at least 10 years to start
> using secure email (i.e., as we know it today). A decade of collective
> experience strongly suggests there must be some new thinking before
> things will be able to move ahead.
Yes. The work provides a view to both improve the email security technologies
X.509 / PKI, PGP and IBE, and develop the specifications for new technology
beyond current limitations.
Cheers,
Ed Gerck
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Lars Eilebrecht wrote:
Lars,
Thanks for your nice words.
In order to make some progress on this, I felt a need to
simplify things into + and -. This makes sense also in
terms of attacks vs problems because a system that has
a lot of problems will likely be used badly (insecurely)
or not at all -- which opens room for attacks. So, both
problems and attacks are negative for security.
[See also my previous reply on this to the posting by James Donald,
in this blog]
That's why I had "X.509 / PKI" -- even though PGP's
WOT doesn't qualify as a PKI (no central management).
They are also fundamentally different in other aspects.
I've summarized this in http://nma.com/papers/certover.pdf
The different technologies are compared in terms of the
market products they support. It's a capability (and lack of
capability) analysis.
The message format (and the application) reflect what
the technology needs and can provide support for. S/MIME
is not the same as PGP/MIME, in the same way that the old
PEM was also different (and there's also PGP without PGP/MIME).
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
[See also my previous reply on this to the posting by James Donald,
in this blog]
This is not so relevant for the analysis.
For example, both X.509 and IBE (suppose) support S/MIME.
However, that doesn't make them equal in terms of their
features (the + in the score cards). You can revoke a X.509 key
and have S/MIME tell you that for X.509 (score a + there)
while you can't revoke an IBE key (doesn't score the +).
However, you could expire both X.509 and IBE keys (even
though Voltage does not say it for their product, it's in
their IBE papers) and, therefore, both score a + there.
Key revocation is expressed in S/MIME differently than in
PGP/MIME, though. In general, a technology's limitation
(for example, no central key revocation in PGP) will
reflect itself in the encoding used and in the product,
which is what is measured to create the score card.
If you're familiar with that product, I'd like to add their
scores to the respective technology column.
Regards,
Ed Gerck
According to Ed:To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm
Nice paper. I don't had time to look at it in detail, but here a
few minor comments ...
Lars,
Thanks for your nice words.
I think it would be better to have different tables for
attacks vs. problems. For example "must pre-enroll rcpts" may
be an "unwanted feature", but it really something different
compared to an attack, i.e., a problem leading to an attacks
such as "open message headers".
In order to make some progress on this, I felt a need to
simplify things into + and -. This makes sense also in
terms of attacks vs problems because a system that has
a lot of problems will likely be used badly (insecurely)
or not at all -- which opens room for attacks. So, both
problems and attacks are negative for security.
[See also my previous reply on this to the posting by James Donald,
in this blog]
Further, I'm not sure about the general categories you have.
"PKI" is a very broad term. PGP and it's web-of-trust is
also some kind of PKI and of course I could build a closed/private
PKI using OpenPGP keys.
That's why I had "X.509 / PKI" -- even though PGP's
WOT doesn't qualify as a PKI (no central management).
They are also fundamentally different in other aspects.
I've summarized this in http://nma.com/papers/certover.pdf
It may be easier to compare the different technologies if
you compare the message format (e.g., S/MIME vs. PGP/MIME)
independent from the rest of the system, i.e., from the PKI.
The different technologies are compared in terms of the
market products they support. It's a capability (and lack of
capability) analysis.
The message format (and the application) reflect what
the technology needs and can provide support for. S/MIME
is not the same as PGP/MIME, in the same way that the old
PEM was also different (and there's also PGP without PGP/MIME).
As "PKI technologies" I would think of X.509-based PKIs (PKIX),
vs. IBE-based vs. OpenPGP-based ...
An attack against "open message headers" is not related to
a system using X.509 certs or OpenPGP keys, but it just
a matter of the message format being used, e.g., S/MIME.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
[See also my previous reply on this to the posting by James Donald,
in this blog]
If I remember correctly most IBE-based system also use
S/MIME or at least something derived from it like the Voltage
IBE product.
This is not so relevant for the analysis.
For example, both X.509 and IBE (suppose) support S/MIME.
However, that doesn't make them equal in terms of their
features (the + in the score cards). You can revoke a X.509 key
and have S/MIME tell you that for X.509 (score a + there)
while you can't revoke an IBE key (doesn't score the +).
However, you could expire both X.509 and IBE keys (even
though Voltage does not say it for their product, it's in
their IBE papers) and, therefore, both score a + there.
And an attack related to how key revocation is handled is
unrelated to a system using S/MIME or PGP/MIME.
Key revocation is expressed in S/MIME differently than in
PGP/MIME, though. In general, a technology's limitation
(for example, no central key revocation in PGP) will
reflect itself in the encoding used and in the product,
which is what is measured to create the score card.
BTW, have you considered adding the Ciphire system to your
comparison (http://www.ciphire.com)?
If you're familiar with that product, I'd like to add their
scores to the respective technology column.
Regards,
Ed Gerck
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Nice paper! I especially liked the cited 'Johnny' paper.
What about denial of service attacks where super large RSA keys are
used or faked which either crash or tie up the server with decryption
and verification of bogus messages. Even a flood of normal
encrypted/signed messages have to be decrypted before the signature can
be checked. I've seen some messaging systems where the client encrypts
first, then signs (opposite of smime) to avoid decrypting invalid
messages on the server.
I used to work with HSMs (hardware crypto & key storage) and we used to
get many requests for accelerated crypto and strong key storage.
Standard interfaces to crypto subsystem was the feature we required.
Some corporate users can justify the cost of this feature. The problem
is inside attacks on software only cryptostores, the feature is
standardization which means crypto engine options are available.
Key-escrow (encryption key only) allows content filtering and law
enforcement agencies to function. Sounds like IBE has that capability.
Also, these email systems are only discretionary - the user has to
choose to send / receive securely. None of them (afaik) support
mandatory security where the security is always on and cant be disabled
or ignored by the user. At least with some clients they can be set to
default to secure which is a bit better. I guess that is a feature of
the email client regardless of the crypto technology though.
Regards,
Simon McMahon
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Hi Ed,
Things that are interesting that may not be in your charts:
Fx = Secure Message Exchange Negotiation
----------------------------------------
Ideally, if a correspondent's email address is known, it should be easy to start the exchange of secure messages with that correspondent. It should be possible to query the entity's email address for any information necessary to initiate exchange of secure message(s). Intent is to not require a single, world-readable directory of all potential email correspondents and their current email address(es), etc. -- the existence of which would likely have disastrous consequences.
F(x+1) = Secure Message Exchange Recipient Privacy
--------------------------------------------------
Conversely, it should be possible for each correspondent to exert their personally desired level of control over just who is able to access to his/her email address and, particularly, the corresponding security profile. Perhaps analagous to Caller-ID, the individual user (recipient) can determine which queries receive valid security information and which are handled in some other way. Intent is to allow desired message exchange but not be forced to spend time handling (mass quantities of) unwanted secure messages.
F(x+2) = Secure Message Exchange Blocking
-----------------------------------------
Ability to "undo" an earlier decision to engage in secure message exchange with a particular correspondent or group of correspondents. I want to "revoke" my credential specifically with respect to future use for communication with certain other correspondent(s).
Obvously, I don't have a specific solution in mind and have not tried to separate these capabilities cleanly. They'll all kind of run together at first. Also, I don't care whether public key, secret key, DH key exchange, x.509 certificates, or (any other crypto technology) is used in any solution.
The main point, at the outset, is to define a compellingly service that has sufficient benefits to drive the efforts necessary to achieve it's development (i.e., as opposed to allocating resources on other activities). All of us have been waiting for at least 10 years to start using secure email (i.e., as we know it today). A decade of collective experience strongly suggests there must be some new thinking before things will be able to move ahead.
Good Luck & Best Regards,
--dg
Things that are interesting that may not be in your charts:
Fx = Secure Message Exchange Negotiation
----------------------------------------
Ideally, if a correspondent's email address is known, it should be easy to start the exchange of secure messages with that correspondent. It should be possible to query the entity's email address for any information necessary to initiate exchange of secure message(s). Intent is to not require a single, world-readable directory of all potential email correspondents and their current email address(es), etc. -- the existence of which would likely have disastrous consequences.
F(x+1) = Secure Message Exchange Recipient Privacy
--------------------------------------------------
Conversely, it should be possible for each correspondent to exert their personally desired level of control over just who is able to access to his/her email address and, particularly, the corresponding security profile. Perhaps analagous to Caller-ID, the individual user (recipient) can determine which queries receive valid security information and which are handled in some other way. Intent is to allow desired message exchange but not be forced to spend time handling (mass quantities of) unwanted secure messages.
F(x+2) = Secure Message Exchange Blocking
-----------------------------------------
Ability to "undo" an earlier decision to engage in secure message exchange with a particular correspondent or group of correspondents. I want to "revoke" my credential specifically with respect to future use for communication with certain other correspondent(s).
Obvously, I don't have a specific solution in mind and have not tried to separate these capabilities cleanly. They'll all kind of run together at first. Also, I don't care whether public key, secret key, DH key exchange, x.509 certificates, or (any other crypto technology) is used in any solution.
The main point, at the outset, is to define a compellingly service that has sufficient benefits to drive the efforts necessary to achieve it's development (i.e., as opposed to allocating resources on other activities). All of us have been waiting for at least 10 years to start using secure email (i.e., as we know it today). A decade of collective experience strongly suggests there must be some new thinking before things will be able to move ahead.
Good Luck & Best Regards,
--dg
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Wed, Dec 07, 2005 at 09:42:03AM -0500, Ed Gerck wrote:
>
>
> To help develop a common yardstick, I would like feedback (also by
> private email) on a list of desirable secure email features as well
> as a list of attacks or problems, with a corresponding score card for
> the secure email technologies X.509 / PKI, PGP and IBE. The paper
> is at http://email-security.net/papers/pki-pgp-ibe.htm
What's missing, except implicitly, is the most important feature of
all. Ease of use and deployment. What do users have to _do_ to get
the software, to get and maintain certificates (if required), and to
send and receive mail.
This is the most important feature because inattention to it has
caused both secure and insecure systems to not get used except by
a small minority of the population. That the system be easy enough
to use that people will actually use it turns out to be as important
as how secure the system is against various threat models. More
important than security against certain more rare threat models.
It's amazing how easy it is to get this wrong. Did you know that
Microsoft Outlook, the most common email program in the world, has
opportunistic e-mail encryption if you
a) Get a certificate (free from thawte)
b) Click two checkboxes
Nobody uses it because of one very simple but giant mistake. If
you turn on the checkboxes, then every time you send mail and
every time you receive encrypted mail, you get a dialog box popping
up asking to confirm if the program can access your private key.
(Also, nobody knows about it, and it uses giant ugly x.509/s-mime)
And one final note -- it is controversial to describe "return receipt"
as a feature. For recipients, that's an anti-feature.
--
Brad Templeton
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
According to Ed:
> To help develop a common yardstick, I would like feedback (also by
> private email) on a list of desirable secure email features as well
> as a list of attacks or problems, with a corresponding score card for
> the secure email technologies X.509 / PKI, PGP and IBE. The paper
> is at http://email-security.net/papers/pki-pgp-ibe.htm
Nice paper. I don't had time to look at it in detail, but here a
few minor comments ...
I think it would be better to have different tables for
attacks vs. problems. For example "must pre-enroll rcpts" may
be an "unwanted feature", but it really something different
compared to an attack, i.e., a problem leading to an attacks
such as "open message headers".
Further, I'm not sure about the general categories you have.
"PKI" is a very broad term. PGP and it's web-of-trust is
also some kind of PKI and of course I could build a closed/private
PKI using OpenPGP keys.
It may be easier to compare the different technologies if
you compare the message format (e.g., S/MIME vs. PGP/MIME)
independent from the rest of the system, i.e., from the PKI.
As "PKI technologies" I would think of X.509-based PKIs (PKIX),
vs. IBE-based vs. OpenPGP-based ...
An attack against "open message headers" is not related to
a system using X.509 certs or OpenPGP keys, but it just
a matter of the message format being used, e.g., S/MIME.
If I remember correctly most IBE-based system also use
S/MIME or at least something derived from it like the Voltage
IBE product.
And an attack related to how key revocation is handled is
unrelated to a system using S/MIME or PGP/MIME.
BTW, have you considered adding the Ciphire system to your
comparison (http://www.ciphire.com)?
ciao...--
Lars Eilebrecht
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
"James A. Donald" 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.
StealthMonger
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
James A. Donald wrote:
Boats are storm rated, however. The point here is how can we
"storm rate" secure email systems?
For example, it might be a good idea to have different tables for
attacks vs. problems (for boats: resisting pirates versus
resisting high waves). For example P13 (must pre-enroll recipients) may
be a problem and it really is something different compared to an
attack, i.e., a problem leading to an attack such as P12 (open message
headers).
However, in order to make some progress in this, I felt a need to
simplify things into + and -. This makes sense also in terms of
attacks vs problems (for email, maybe not for boats!) because a
secure email system that has a lot of problems will likely be used
badly (insecurely) or not at all -- which opens room for attacks.
So, both problems and attacks are negative for security.
What I'm saying is that we can, and do in many other cases,
compare different systems in terms of their features and
shortcomings. Irrespectively of how we may further classify them,
a feature is + and a shortcoming is -. For example, that's how your
car value is estimated when you sell it -- by how many negative and
positive points it gets. It doesn't matter if the negative points
came from a dent or an absence of air bags, they all count negatively.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
To do this, the paper asks two questions:
(1) what are the product's capabilities in terms of a list of desired
features (the +), and
(2) what are the product's shortcomings in terms of a list of attack/
problems (the -),
for each main market product using those technologies and assigns each
score (+ or -) to the technology used by that product. At the end
of this algorithm, scanning enough products, we have a list of all
capabilities and all shortcomings that affect each technology.
Of course, each feature and problem/attack is intended as optional --
you can pick and choose what you want from the list, to make your
own subset of the score card, valid for your needs (and amount of
money you want to pay).
These lists are an intrinsic "yardstick" that we can use to both rate each
technology and also, if we want, each individual product. For example, a
product that has 80% of the positive score and 20% of the negative score
for that technology is possibly better than a product using the same
technology that would have 20% of the positive and 80% of the negative
for that technology. We can, in the same way, compare products using
different technologies, comparing their score cards.
For example P1: giving others the ability to get your private
key at a server without your knowledge or consent.
Anything we can do to negate "after the fact investigations" is
useful , such as protecting the email headers (communication
security, not just message security). The paper's score card
reflects several aspects of this, in its positive and
negative scores.
For example P1 to P8.
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?
Store and forward makes it reliable -- nothing needs to be
100% online 100% of the time (a totally improbable event).
Cheers,
Ed Gerck
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,
Boats are storm rated, however. The point here is how can we
"storm rate" secure email systems?
For example, it might be a good idea to have different tables for
attacks vs. problems (for boats: resisting pirates versus
resisting high waves). For example P13 (must pre-enroll recipients) may
be a problem and it really is something different compared to an
attack, i.e., a problem leading to an attack such as P12 (open message
headers).
However, in order to make some progress in this, I felt a need to
simplify things into + and -. This makes sense also in terms of
attacks vs problems (for email, maybe not for boats!) because a
secure email system that has a lot of problems will likely be used
badly (insecurely) or not at all -- which opens room for attacks.
So, both problems and attacks are negative for security.
What I'm saying is that we can, and do in many other cases,
compare different systems in terms of their features and
shortcomings. Irrespectively of how we may further classify them,
a feature is + and a shortcoming is -. For example, that's how your
car value is estimated when you sell it -- by how many negative and
positive points it gets. It doesn't matter if the negative points
came from a dent or an absence of air bags, they all count negatively.
I'm looking into each product individually and building a collective
metric based on technologically-neutral specifications for + and -.
To do this, the paper asks two questions:
(1) what are the product's capabilities in terms of a list of desired
features (the +), and
(2) what are the product's shortcomings in terms of a list of attack/
problems (the -),
for each main market product using those technologies and assigns each
score (+ or -) to the technology used by that product. At the end
of this algorithm, scanning enough products, we have a list of all
capabilities and all shortcomings that affect each technology.
Of course, each feature and problem/attack is intended as optional --
you can pick and choose what you want from the list, to make your
own subset of the score card, valid for your needs (and amount of
money you want to pay).
These lists are an intrinsic "yardstick" that we can use to both rate each
technology and also, if we want, each individual product. For example, a
product that has 80% of the positive score and 20% of the negative score
for that technology is possibly better than a product using the same
technology that would have 20% of the positive and 80% of the negative
for that technology. We can, in the same way, compare products using
different technologies, comparing their score cards.
Problem 1: The primary weakness of existent email is its vulnerability to after the fact investigations.
For example P1: giving others the ability to get your private
key at a server without your knowledge or consent.
Anything we can do to negate "after the fact investigations" is
useful , such as protecting the email headers (communication
security, not just message security). The paper's score card
reflects several aspects of this, in its positive and
negative scores.
Problem 2: The secondary weakness is ease of forgery.
For example P1 to P8.
Crap with certificate authorities or web of trust just is not flying, and is not going to fly.
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?
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.
Store and forward makes it reliable -- nothing needs to be
100% online 100% of the time (a totally improbable event).
Cheers,
Ed Gerck
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.
To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm
The list of desirable secure email features and the list of attacks /
problems might also be useful in terms of improving secure email
support.
Cheers,
Ed Gerck
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.
To help develop a common yardstick, I would like feedback (also by
private email) on a list of desirable secure email features as well
as a list of attacks or problems, with a corresponding score card for
the secure email technologies X.509 / PKI, PGP and IBE. The paper
is at http://email-security.net/papers/pki-pgp-ibe.htm
The list of desirable secure email features and the list of attacks /
problems might also be useful in terms of improving secure email
support.
Cheers,
Ed Gerck
Subscribe to:
Posts (Atom)