Hagai Bar-El

Information Security Specialist


HBAREL.COM  
 
 
 

Is E-mail encryption really too complex?


Message # 1

Date: Mon, 08 May 2006
To: practicalsecurity at hbarel.com
From: Hagai Bar-El
Subject: [PracticalSecurity] Is E-mail encryption really too complex?



Hello,


I would like to share an opinion with you, and possibly hear comments.


Is E-mail encryption really too complex?
http://www.hbarel.com/Blog/entry0008.html

To summarize my opinion, most people don't use e-mail encryption not because it's not easy enough or because it's too intrusive, but simply because they don't truly believe they need it. If any vendor wants to increase his sales of e-mail encryption products, he should focus less on sharpening the already-sharp GUI and more on evangelism...


Hagai.





Message # 2

Date: Sun, 07 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Hagai Bar-El wrote:
Hello,
I would like to share an opinion with you, and possibly hear comments.
Is E-mail encryption really too complex?
http://www.hbarel.com/Blog/entry0008.html
To summarize my opinion, most people don't use e-mail encryption not
because it's not easy enough or because it's too intrusive, but simply
because they don't truly believe they need it. If any vendor wants to
increase his sales of e-mail encryption products, he should focus less
on sharpening the already-sharp GUI and more on evangelism...
But ... people use encryption in Skype. And all users of SSH face a slightly complicated interface, and always use it.
The advantage that those tools have is that there is only one mode, and it's secure. There is no choice.
Which is why I make this a rule in things I design - there is only one way to do things and it has it all.
Email crypto of course faces a separate problem ...
it is trying to be compatible with a tool that isn't secure. Maybe the economics of the situation is that this is unlikely to work.
Something like HTTPS shows how difficult it is to mix secure modes with non-secure mode.
iang

Message # 3

Date: Sun, 7 May 2006
From: Jarda
To: PracticalSecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

On Sun, 07 May 2006 21:25:00 +0200
Hagai Bar-El wrote:
Hello,
I would like to share an opinion with you, and possibly hear
comments.
Is E-mail encryption really too complex?
http://www.hbarel.com/Blog/entry0008.html
To summarize my opinion, most people don't use e-mail
encryption not because it's not easy enough or because it's
too intrusive, but simply because they don't truly believe
they need it. If any vendor wants to increase his sales of
e-mail encryption products, he should focus less on sharpening
the already-sharp GUI and more on evangelism...
Hagai.
Consider also that most people use M$ Outlook Express and how do you do encryption in Outlook? There were some plugins for GPG but there were some problems with them. Like no GPG/Mime, inability of Outlook to maintain the message's exact formatting and though inability to verify the signature... Unless they did something about it, which is never sure with Microsoft. E.g. Outlook still probably doesn't quote messages in quoted-printable, which is an eons old bug.
So as long as most people use this gobshite, encryption is unusable. Personally I know only two persons with a mailer supporting encryption. To whom should I encrypt? I would prefer, you never know who and where sneaks in your mail. And whatever you say, unless talking about weather, can be abused to cause you troubles.

Message # 4

Date: Mon, 08 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello Ian,
At 07/05/06 22:01, Ian G wrote:
But ... people use encryption in Skype. And all
users of SSH face a slightly complicated interface,
and always use it.
People use encryption in Skype, as you pointed out, because they have no choice. Even if they had - security in Skype comes at zero cost (cost in complexity, ease-of-use, etc.) When features start to cost something people start to think if it's worth it, and when it comes to security they usually decide that it's not.
The advantage that those tools have is that there is
only one mode, and it's secure. There is no choice.
Which is why I make this a rule in things I design -
there is only one way to do things and it has it all.
I agree. Whenever this can be done this is certainly the way to go.
However, not in all systems it is possible. Sometimes security has significant costs when activated, and does not need to be applied to all users. In these cases, the users must be given a choice and most of them will decide to skip security.
Email crypto of course faces a separate problem ...
it is trying to be compatible with a tool that isn't
secure. Maybe the economics of the situation is that
this is unlikely to work.
I think so too. As long as secure e-mail clients need to interoperate with non-secure clients, they will have to support insecure modes. As long as insecure modes are supported and are easier to use than secure ones, most people will select the insecure ones.
Something like HTTPS shows how difficult it is to mix
secure modes with non-secure mode.
Yes. In general, I think that "security level" is an attribute that needs to be applied on the problem-world transaction/operation level rather than at a technical level. E.g. A visit to a web-site needs to be either secure or not, without different security associations for different frames. A transaction (the way the user, not the programmer, knows it) needs to either be secure or not, rather than have some fields encrypted and authenticated and some sent in the clear.
Hagai.

Message # 5

Date: Mon, 08 May 2006
To: Jarda
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: PracticalSecurity at hbarel.com

Hello Jarda,
At 07/05/06 22:33, Jarda wrote:
Consider also that most people use M$ Outlook Express and how do
you do encryption in Outlook? There were some plugins for GPG but
there were some problems with them. Like no GPG/Mime, inability
of Outlook to maintain the message's exact formatting and though
inability to verify the signature... Unless they did something
about it, which is never sure with Microsoft. E.g. Outlook still
probably doesn't quote messages in quoted-printable, which is an
eons old bug.
You certainly have a point about the usability of the Outlook plugins. Yet, even if you forgo the use of plugins altogether and encrypt the messages through the clipboard (WinPT?) or use the context-menu to encrypt files before you send them, this is not *that* big of an issue if you really believe you need encryption. I personally never use plugins but encrypt the material separately - doesn't add more than a few seconds and gives you visible assurance that encryption has taken place.
So as long as most people use this gobshite, encryption is
unusable. Personally I know only two persons with a mailer
supporting encryption. To whom should I encrypt? I would
prefer, you never know who and where sneaks in your mail. And
whatever you say, unless talking about weather, can be abused to
cause you troubles.
This is a matter of personal taste, I guess. I personally don't believe most of my e-mail can get me into troubles if found. I therefore encrypt only what I believe needs to be encrypted for financial reasons. It ends up as less than 1% of the messages I write.
BTW, by using encryption only for what is less than 1% of your mail you can improve the security of this 1%. I put my key-rings on a removable drive. When I need it I put it in, do the crypto, and take it out. Needless to say, I don't cache the passwords. I would not be able to follow this procedure if I needed to use my private key for every message I receive...
Hagai.

Message # 6

Date: Sun, 14 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
Ian G wrote:
But ... people use encryption in Skype. And all users
of SSH face a slightly complicated interface, and
always use it.
But it is only slightly complicated. Setting up encrypted email, or setting up an https server, is hellish.
The overhead for SSH is minute. Thee only security overhead the user encounters is a dialog saying "Hey, this client has never connected to this server before, shall I memorize this as the correct server for the server named so and so", which does not surprise, confuse or mystify him.
In contrast, PKI overhead is horrific. In order for A and B to have a relationship, they have to arrange a relationship with C. Who the hell is C? The average user has absolutely no idea, and we, who do understand, still find it mighty hard.
In the case of Skype, C is Skype, and the Skype install handles it automagically for you without you knowing or caring - which means that Skype is not able to prove that you really are Elrond, but is able to prove that you are the same user calling himself Elrond as called himself Elrond last time - which is all that SSH proves, and in practice all that we use or need.
As I am fond of pointing out, if someone clicks on the egold certificate, one does not get a message "Verisign declares this is the real e-gold, which has been in business several years without stealing anyone's money so far". Instead one gets the message that the web site is owned by "Gold and Silver Reserve, Inc"
Huh? Who the hell is Gold and Silver Reserve? - Answer: an overseas shell company established to avoid taxes and regulation, whose registration was allowed to lapse. Not particularly reassuring, but who cares? No one is ever going click on the certificate anyway.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
kiHi7tjoE7d1EwBcE3E2kYsa8uf/nRJtXE9kQLp/
44G6T6uZGuX2CeiNeKYlkxNB1SdieJ70fUNT1McEQ

Message # 7

Date: Sun, 14 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
Hagai Bar-El wrote:
I agree. Whenever this can be done this is certainly > the way to go. However, not in all systems it is > possible. Sometimes security has significant costs > when activated, and does not need to be applied to all > users.
Security should have near zero cost. It should come for free with contact list and alias management.
PKI and PGP security has significant costs because it tries to ensure true names. But in practice people do not use true names - see the e-gold certificate which uses an unknown shell company name.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
OWcoBAok9RKh7R0e79XBLLbV816079GAowo/mrmd
43d6l3fHEtvPMd0i+1C6bnaurifvqGNAgFUmu63NM

Message # 8

Date: Sun, 14 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Hagai Bar-El wrote:
Hello Ian,
At 07/05/06 22:01, Ian G wrote:
But ... people use encryption in Skype. And all
users of SSH face a slightly complicated interface,
and always use it.
People use encryption in Skype, as you pointed out, because they have no
choice. Even if they had - security in Skype comes at zero cost (cost in
complexity, ease-of-use, etc.) When features start to cost something
people start to think if it's worth it, and when it comes to security
they usually decide that it's not.
The problem is characterised by Kerckhoffs' 6th principle, being:
Finally, it is necessary, given the circumstances that command
its application, that the system be easy to use, requiring
neither mental strain nor the knowledge of a long series of
rules to observe.
https://www.financialcryptography.com/mt/archives/000195.html
What Kerckhoffs was looking at was the soldier in the field - how does he encrypt his messages to send to headquarters. If it is even slightly cumbersome, the poorly trained grunt will simply send it in the clear.
That is, avoid the security system.
As a soldier in my dim past, I recall trying to write encrypted messages in the dark, in the rain, and in a hurry. His usage model - but the same concept applies at the PC.
The only way to achieve this reliably is to:
a. provide security at zero cost
b. provide security always (cannot turn off)
Which is why Skype works. SSH almost achieves it, the "no cost" part is not quite there, but as James points out it is good enough.
The advantage that those tools have is that there is
only one mode, and it's secure. There is no choice.
Which is why I make this a rule in things I design -
there is only one way to do things and it has it all.
I agree. Whenever this can be done this is certainly the way to go.
However, not in all systems it is possible. Sometimes security has
significant costs when activated, and does not need to be applied to all
users. In these cases, the users must be given a choice and most of them
will decide to skip security.
In that case, I humbly submit that such systems will suffer poor security, because the users will just turn it off. Why bother?
(It would be apropos at this point to bring in an example where there are significant costs, and the user must be given a choice.)
Email crypto of course faces a separate problem ...
it is trying to be compatible with a tool that isn't
secure. Maybe the economics of the situation is that
this is unlikely to work.
I think so too. As long as secure e-mail clients need to interoperate
with non-secure clients, they will have to support insecure modes. As
long as insecure modes are supported and are easier to use than secure
ones, most people will select the insecure ones.
Something like HTTPS shows how difficult it is to mix
secure modes with non-secure mode.
Yes. In general, I think that "security level" is an attribute that
needs to be applied on the problem-world transaction/operation level
rather than at a technical level. E.g. A visit to a web-site needs to be
(snip)
Make them both secure all the time. It's much easier that way. IMO, the "need" for an insecure usage is much exaggerated.
(Of course, this whole debate skips the meaning of "secure" but that IMO is subsidiary to the question of usability. c.f., Kerckhoffs' 6th, above.)
iang

Message # 9

Date: Sun, 14 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

James A. Donald wrote:
--
Ian G wrote:
But ... people use encryption in Skype. And all users
of SSH face a slightly complicated interface, and
always use it.
But it is only slightly complicated. Setting up
encrypted email, or setting up an https server, is
hellish.
The overhead for SSH is minute. Thee only security
overhead the user encounters is a dialog saying "Hey,
this client has never connected to this server before,
shall I memorize this as the correct server for the
server named so and so", which does not surprise,
confuse or mystify him.
Right. It works.
In contrast, PKI overhead is horrific. In order for A
and B to have a relationship, they have to arrange a
relationship with C. Who the hell is C? The average
user has absolutely no idea, and we, who do understand,
still find it mighty hard.
Well, we also know it to be specious. It is based on a long history of false assumptions; ones which are silly for HTTPS and downright ludicrous in the case of the S/MIME - "what, you are saying that my relationship with Verisign is stronger than with my Mom and my mates?"
In the case of Skype, C is Skype, and the Skype install
handles it automagically for you without you knowing or
caring - which means that Skype is not able to prove
that you really are Elrond, but is able to prove that
you are the same user calling himself Elrond as called
himself Elrond last time - which is all that SSH proves,
and in practice all that we use or need.
Yup!
As I am fond of pointing out, if someone clicks on the
egold certificate, one does not get a message "Verisign
declares this is the real e-gold, which has been in
business several years without stealing anyone's money
so far". Instead one gets the message that the web site
is owned by "Gold and Silver Reserve, Inc"
Huh? Who the hell is Gold and Silver Reserve? - Answer:
an overseas shell company established to avoid taxes and
regulation, whose registration was allowed to lapse. Not
(snip)
Actually, you have it backwards - e-gold was the company in Nevis, and G&SR is incorporated in FL.
Also, it's all the same now - as they allowed the company to lapse, the effective jurisdiction falls back to the operators in FL. (IANAL - that's a layman's guess.) And, as the Feds are all over them these days, they'll arrange matters to keep it that way.
But, yes, your essential point is correct. Nobody cared enough about the jurisdictions, once they had a feeling that the people were real and the service worked.
iang

Message # 10

Date: Sun, 14 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello Ian,
At 14/05/06 11:12, Ian G wrote:
Hagai Bar-El wrote:
The advantage that those tools have is that there is
only one mode, and it's secure. There is no choice.
Which is why I make this a rule in things I design -
there is only one way to do things and it has it all.
I agree. Whenever this can be done this is certainly the way to go.
However, not in all systems it is possible. Sometimes security has
significant costs when activated, and does not need to be applied
to all users. In these cases, the users must be given a choice and
most of them will decide to skip security.
In that case, I humbly submit that such systems
will suffer poor security, because the users will
just turn it off. Why bother?
What we tend to forget is that even though the "poorly trained grunt soldier" matches the profile of most users, the rule did not mean to apply to the colonels. The fact that most people don't bother to switch security on when having it as an option does not imply that we should not bother building the system, or that the system is insecure.
System's security is measured to the light of a threat model. If the threat model is such that indicates a threat only in 1% of the cases the system is used then having security switched on 1% of the times (given it's the matching 1%) does not make the system insecure.
99.9% of the e-mails are not encrypted, but to see this as a failure of the system we need to discuss how many of the e-mail should have been encrypted was the system designed and running properly. Of course, it never hurts to encrypt all, but to judge that a system is insecure just because security is often left off we need to actually see how many "misses" we had, that is, cases in which security was supposed to be turned on, yet was not.
I agree, and always had, that systems that are made for the public and/or that can easily be built with one mode (e.g. Skype) should be built that way, I am not arguing on this, but the fact that a system has security as an option does not for itself make it insecure.
(It would be apropos at this point to bring in an
example where there are significant costs, and the
user must be given a choice.)
Take a P2P (hence, non-server-based) system that secures IRC messages using either PKI or symmetric keys. For the purpose of actually activating this, the user has to generate a key and negotiate it with each and every peer he corresponds with. Although such a secure system can be very useful in some cases, it would not be reasonable to force the user into encrypting each and every session with each and every peer, e.g. by forcing a prompt for a key before the first message in a session goes out. The user should be able to decide that this particular exchange needs not be secure as opposed to some other exchanges which must.
When I chat about tea recipes with someone I don't know over IRC in a tea-lovers forum, I would not like to be forced to call him on the phone and negotiate keys. When I communicate with the office over a public WLAN when I am abroad, I am happy to do this key negotiation and know that I can chat freely about sensitive stuff.
A mass roll out of IRC keys will not be worth it for anyone and will make the entire system much more cumbersome for very little benefit.
Moreover, some people see the ability to repudiate and the non-linkability as an important property of IRC, which will be lost if keying is forced when using the system.
I think so too. As long as secure e-mail clients need to
interoperate with non-secure clients, they will have to support
insecure modes. As long as insecure modes are supported and are
easier to use than secure ones, most people will select the insecure ones.
Something like HTTPS shows how difficult it is to mix
secure modes with non-secure mode.
Yes. In general, I think that "security level" is an attribute that
needs to be applied on the problem-world transaction/operation
level rather than at a technical level. E.g. A visit to a web-site
needs to be either secure or not, without different security
associations for different frames. A transaction (the way the user,
not the programmer, knows it) needs to either be secure or not,
rather than have some fields encrypted and authenticated and some
sent in the clear.
Make them both secure all the time. It's much
easier that way. IMO, the "need" for an insecure
usage is much exaggerated.
I agree that security comes for no cost at most times, and thus there is no motivation for insecure modes, but I claim that this is so only when you can assume the key management infrastructure to be pre-existent. When registered keys are not there yet, and given there is no world-wide repository in which everyone is enrolled automatically, this is far from being "no-cost security".
In some systems always-secure is easy - in some systems it's not...
Best,
Hagai.

Message # 11

Date: Sun, 14 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello Ian,
At 14/05/06 11:12, Ian G wrote:
Hagai Bar-El wrote:
The advantage that those tools have is that there is
only one mode, and it's secure. There is no choice.
Which is why I make this a rule in things I design -
there is only one way to do things and it has it all.
I agree. Whenever this can be done this is certainly the way to go.
However, not in all systems it is possible. Sometimes security has
significant costs when activated, and does not need to be applied
to all users. In these cases, the users must be given a choice and
most of them will decide to skip security.
In that case, I humbly submit that such systems
will suffer poor security, because the users will
just turn it off. Why bother?
What we tend to forget is that even though the "poorly trained grunt soldier" matches the profile of most users, the rule did not mean to apply to the colonels. The fact that most people don't bother to switch security on when having it as an option does not imply that we should not bother building the system, or that the system is insecure.
System's security is measured to the light of a threat model. If the threat model is such that indicates a threat only in 1% of the cases the system is used then having security switched on 1% of the times (given it's the matching 1%) does not make the system insecure.
99.9% of the e-mails are not encrypted, but to see this as a failure of the system we need to discuss how many of the e-mail should have been encrypted was the system designed and running properly. Of course, it never hurts to encrypt all, but to judge that a system is insecure just because security is often left off we need to actually see how many "misses" we had, that is, cases in which security was supposed to be turned on, yet was not.
I agree, and always had, that systems that are made for the public and/or that can easily be built with one mode (e.g. Skype) should be built that way, I am not arguing on this, but the fact that a system has security as an option does not for itself make it insecure.
(It would be apropos at this point to bring in an
example where there are significant costs, and the
user must be given a choice.)
Take a P2P (hence, non-server-based) system that secures IRC messages using either PKI or symmetric keys. For the purpose of actually activating this, the user has to generate a key and negotiate it with each and every peer he corresponds with. Although such a secure system can be very useful in some cases, it would not be reasonable to force the user into encrypting each and every session with each and every peer, e.g. by forcing a prompt for a key before the first message in a session goes out. The user should be able to decide that this particular exchange needs not be secure as opposed to some other exchanges which must.
When I chat about tea recipes with someone I don't know over IRC in a tea-lovers forum, I would not like to be forced to call him on the phone and negotiate keys. When I communicate with the office over a public WLAN when I am abroad, I am happy to do this key negotiation and know that I can chat freely about sensitive stuff.
A mass roll out of IRC keys will not be worth it for anyone and will make the entire system much more cumbersome for very little benefit.
Moreover, some people see the ability to repudiate and the non-linkability as an important property of IRC, which will be lost if keying is forced when using the system.
I think so too. As long as secure e-mail clients need to
interoperate with non-secure clients, they will have to support
insecure modes. As long as insecure modes are supported and are
easier to use than secure ones, most people will select the insecure ones.
Something like HTTPS shows how difficult it is to mix
secure modes with non-secure mode.
Yes. In general, I think that "security level" is an attribute that
needs to be applied on the problem-world transaction/operation
level rather than at a technical level. E.g. A visit to a web-site
needs to be either secure or not, without different security
associations for different frames. A transaction (the way the user,
not the programmer, knows it) needs to either be secure or not,
rather than have some fields encrypted and authenticated and some
sent in the clear.
Make them both secure all the time. It's much
easier that way. IMO, the "need" for an insecure
usage is much exaggerated.
I agree that security comes for no cost at most times, and thus there is no motivation for insecure modes, but I claim that this is so only when you can assume the key management infrastructure to be pre-existent. When registered keys are not there yet, and given there is no world-wide repository in which everyone is enrolled automatically, this is far from being "no-cost security".
In some systems always-secure is easy - in some systems it's not...
Best,
Hagai.

Message # 12

Date: Mon, 15 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
Hagai Bar-El wrote:
What we tend to forget is that even though the "poorly > trained grunt soldier" matches the profile of most > users, the rule did not mean to apply to the colonels.
The fact that most people don't bother to switch > security on when having it as an option does not imply > that we should not bother building the system, or that > the system is insecure.
I observe that I continually receive genuine, but unsigned, emails from banks that are under phishing attacks, with "click here" links all over the place.
Your highly trained colonels appear to be AWOL.
Even Amazon, usually the epitome of good practice, keeps sending out "please phish me" emails. The only companies under phish attack that send out signed emails are e-gold and pecunix - probably a result of their cypherpunk backgrounds.
Ebay has adopted the non cryptographic practice of including a widely shared secret in its emails to authenticate them - weak, but considerably better than banking practice. It stops mass phishing spams, but renders individually targeted frauds trivial. If one is scamming a particular individual, one can easily send them emails that appear to be from Ebay.
99.9% of the e-mails are not encrypted, but to see > this as a failure of the system we need to discuss how > many of the e-mail should have been encrypted was the > system designed and running properly.
100% of emails concerning money, for example the notices I receive of my credit cards, bank accounts, stocks, real estate, and so forth, should be signed, and most of them should be encrypted.
They are not, and your "colonels" are in charge of them.
Any system where it is easy enough to encrypt what needs to be encrypted, would be easier if it encrypted them all. SSH does not support a readily accessible unencrypted mode, not because they wanted to force the great unwashed masses to use encryption, but because more options means more work for the user. To give the masses easy access to what they need, they relegated what was not needed to be less accessible. Who needs unencrypted mode?
Take a P2P (hence, non-server-based) system that > secures IRC messages using either PKI or symmetric > keys. For the purpose of actually activating this, the > user has to generate a key and negotiate it with each > and every peer he corresponds with.
No he does not. His client does.
His client already has to do petname management. Under the hood, that petname management could well implement a full Zooko's triangle on public keys, ensuring, as with Skype, that each instance of a nym corresponded to the same person, providing added utility, but no significant added user overhead, with most users, most of the time, not knowing or caring about the encryption.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
QGw1PfbCnxURJyWkQjFESvrgn2S2ob6HPOsLn7zv
4WJOSUIiiw9IrmapRODpa0onlo2pK8vQftle/GRlq

Message # 13

Date: Tue, 16 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
Hagai Bar-El:
for this to be really useful, some real identity > should be set behind the client.
But "real" identity is not useful, for there are no true names, only true relationships. PKI is burdensome because we do not, in fact, want to use true names.
Supposedly e-gold is not the true name of e-gold - at least that is what one discovers when one delves deeply enough into official truth.
Also, a Skype-like model requires a central trusted > server to initially bind names to keys. An SSH-model > would work, but still omits the actual user identity > from the security model.
People trust nyms, not identities. What is a brand name but a nym?
What we really need is true relationship tracking: We need our client to tell us that this communication really does from xxxxx at xxxxxx.xxx, whom we previously posted to. This other communication really does come from the web site xxxxxxx.com, with which I created a login, and the click to login links are provided by my client, or at least blessed by my client, not the html in the email. PKI is not necessary for this, not particularly useful for this.
Sometimes it's good enough - something it's not. For > example - if the communication is one-time in nature > then trusting the key once and caching it does not add > much.
What we urgently need to protect are communications from our banks, employers, credit card companies, Amazon, and ebay - none of which are "one time"
A "one time" certified communication would work like this: Zacks puts up an ad "Get your mortgage at Zacks.
Real cheap!" I then go to Verisign to see how worthy Zacks is. Except, of course, I don't.
If a communication is truly one time in nature, there is little incentive for a man in the middle attack, so certification does not add much. I am not going to do business with e-gold because Verisign says it is owned by Gold and Silver reserve. I am going to do business with e-gold because other people do - I want to access the same entity that Joe Random accessed. A full Zooko's triangle system would handle that considerably better than PKI does.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
GqOosUErdU7+psAgLuhs7VgtwYAtt5GultKMDTS6
4Mn1Oi4V6GeL2po0vqtqwcjnK2892g2M5sCIkf6/9

Message # 14

Date: Tue, 16 May 2006
From: Stephan Neuhaus
To: jamesd at echeque.com
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

James A. Donald wrote:
Security should have near zero cost. It should come for
free with contact list and alias management.
This seems to be the general consensus, but the more often I see it repeated, mantra-like, in security mailing lists, the more confused I am.
The very notion of security depends on a threat model. To demand that "security" have near-zero cost independent of the threat model is akin to demanding world peace.
Also, near-zero cost for the user does not translate into near-zero cost for the developer. To demand that companies (or individual programmers) make the investment only because it's the right thing to do is unrealistic. Companies must be given an economic incentive that is greater than the cost of implementing security measures before they will begin to do so. This is especially true for "no-cost" security which is often significantly harder to implement and maintain than ordinary software components.
To return to the question of email, I agree with you that PGP et al. can incur significant cognitive overheads (as it were) because they try to ensure true names. (Still, that is true for PKI more than it is for PGP, because it is *I* who decides who to trust and what key IDs mean.) That may not be what email users need, so there may be a cheaper way of ensuring "security" than this. I wonder why no-one has yet come up with one?
Fun,
Stephan
PS: I find Enigmail integration into Thunderbird very painless and very convenient.

Message # 15

Date: Tue, 16 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Hagai Bar-El wrote:
I agree. Whenever this can be done this is certainly the way to go.
However, not in all systems it is possible. Sometimes security has
significant costs when activated, and does not need to be applied to
all users. In these cases, the users must be given a choice and most
of them will decide to skip security.
In that case, I humbly submit that such systems
will suffer poor security, because the users will
just turn it off. Why bother?
What we tend to forget is that even though the "poorly trained grunt
soldier" matches the profile of most users, the rule did not mean to
apply to the colonels.
( We have to be careful with analogues of course, but your typical colonel is no more adept at tech than the grunt. In practice, they are even less adept and have to have trained specialists. So we generally end up with two (or more) systems - the high security ones matched to the expensive communicators, which includes specialists to drive them, and the low sec systems where we can't afford the specialists. )
The fact that most people don't bother to switch
security on when having it as an option does not imply that we should
not bother building the system, or that the system is insecure.
System's security is measured to the light of a threat model. If the
threat model is such that indicates a threat only in 1% of the cases the
system is used then having security switched on 1% of the times (given
it's the matching 1%) does not make the system insecure.
(snip)
I think I mildly disagree with that hypothesis, but I'm not sure how to prove it one way or another. And that may be the problem - how do you develop an acceptable rate of encrypting the right messages?
In a sense, we would have to look at the threat scenarios for say email. For the most part, our best evidence of this is things like discovery in legal cases (not because crypto would have saved them but it gives a guide to the quality of a sensitive versus insensitive email).
There, I would hazard a guess that it is hard to predict in advance which email would become the smoking gun. The closer we get to defining it, the more it seems that we should just not do any sensitive emails at all and talk in the bar after work.
I agree, and always had, that systems that are made for the public
and/or that can easily be built with one mode (e.g. Skype) should be
built that way, I am not arguing on this, but the fact that a system has
security as an option does not for itself make it insecure.
No, it doesn't make it insecure, but it does mean we are now in the realm of assumptions. The security model is now complete only if certain user assumptions are met - that is, the user has indeed turned on security for the important message.
Skype, et al, on the other hand does not rely on that assumption.
(It would be apropos at this point to bring in an
example where there are significant costs, and the
user must be given a choice.)
Take a P2P (hence, non-server-based) system that secures IRC messages
using either PKI or symmetric keys. For the purpose of actually
activating this, the user has to generate a key and negotiate it with
each and every peer he corresponds with. Although such a secure system
can be very useful in some cases, it would not be reasonable to force
the user into encrypting each and every session with each and every
peer, e.g. by forcing a prompt for a key before the first message in a
(snip)
Well, I would simply exchange the public keys as part of the protocol and use them. Create a sense of key-relationship, by recording how many times it is seen. Allow external verification.
When I chat about tea recipes with someone I don't know over IRC in a
tea-lovers forum, I would not like to be forced to call him on the phone
and negotiate keys. When I communicate with the office over a public
WLAN when I am abroad, I am happy to do this key negotiation and know
that I can chat freely about sensitive stuff.
Right. But that proposal is based on a sense that only a voice-confirmed key is worth it in our security model.
If we have a (lower) value for a non-voice-confirmed key, instead of no value, the whole problem becomes much simpler.
A mass roll out of IRC keys will not be worth it for anyone and will
make the entire system much more cumbersome for very little benefit.
Moreover, some people see the ability to repudiate and the
non-linkability as an important property of IRC, which will be lost if
keying is forced when using the system.
Oh, there are lots of flaws with those systems.
But some flaws are just strawmen. Repudiability is one such.
I agree that security comes for no cost at most times, and thus there is
no motivation for insecure modes, but I claim that this is so only when
you can assume the key management infrastructure to be pre-existent.
When registered keys are not there yet, and given there is no world-wide
repository in which everyone is enrolled automatically, this is far from
being "no-cost security".
In some systems always-secure is easy - in some systems it's not...
Well, true. It is important to define our user base. I generally assume for sake of argument the average Internet application, including those things known as ecommerce.
I generally reject esoterica such as national security, not because it is a "demanding" field but because there is too much money and agenda washing around, so it isn't worth the bother to argue through it.
In contrast, on the net, people are generally very grateful for security that comes at next to no cost. E.g., Skype. They don't bring up strawmen arguments like the security model is not CC confirmed (as a hypothetical argument), they just use it.
So the question here is - is there a user base where we need to involve those up front costs that make security hard? Or can we simply assume that all users will be adequately served by opportunistic startup, and an option later to go to "voice-confirmed" mode?
(I argue the latter, of course.)
iang

Message # 16

Date: Tue, 16 May 2006
From: Ian G
To: Stephan Neuhaus
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Stephan Neuhaus wrote:
James A. Donald wrote:
Security should have near zero cost. It should come for
free with contact list and alias management.
This seems to be the general consensus, but the more often I see it
repeated, mantra-like, in security mailing lists, the more confused I am.
:) The answer is, there is soooo much to unlearn.
The very notion of security depends on a threat model. To demand that
"security" have near-zero cost independent of the threat model is akin
to demanding world peace.
Well, if one stops there, yes :)
But when we say "near-zero cost" we aren't implying it be independent of the threat model - what we are saying is that we will cover the threat model as best we can with the low cost limitation, and stop there.
If there is anything we can't cover without cost, then it *remains uncovered*. (And it will be disclosed, in general.)
This is the old "SSH flaw" - in theory anyone can do an MITM on the first setup. SSH said, "well, that's too expensive to cover so we won't." That statement is well known ... what is much less well known is that the threat of the MITM is very low risk. So tiny it is more or less unmeasurable, and therefore it is an unvalidated threat, only a theoretical threat.
In practice, most systems can operate to these sorts of decisions. We just need to make the decisions with clear thoughts and assumptions - which is much harder to do than write.
Also, near-zero cost for the user does not translate into near-zero cost
for the developer. To demand that companies (or individual programmers)
make the investment only because it's the right thing to do is
unrealistic. Companies must be given an economic incentive that is
greater than the cost of implementing security measures before they will
begin to do so. This is especially true for "no-cost" security which
is often significantly harder to implement and maintain than ordinary
(snip)
Couldn't agree more. Except, in general, no-cost security is significantly easier to implement than (for example) the PKI standard model. (I know this because I do it.) However, in order to do it, what one needs to do is wade through all the original assumptions and strike them down. One by one.
Once that is done, it is just another engineering problem.
E.g., above - the MITM is not a threat - so don't cover it. http://iang.org/ssl/mallory_wolf.html is an old rant, still true, afaik.
Some others:
* digital signing is nothing to do with humans signing.
(effects S/MIME drastically).
* non-repudiation does not exist
* repudiation of any form is not economic * public/private keys are so cheap they should be made
on demand
* connections are trouble
* CAs introduce a weak point, called the TTP because you
have to trust it; non-CA designs are by default stronger
There are lots more ... here's a whole paper on the flaws in PKI: http://iang.org/ssl/pki_considered_harmful.html
You'll see it is very very long. There are a *lot* of assumptions that have to be unlearnt.
To return to the question of email, I agree with you that PGP et al. can
incur significant cognitive overheads (as it were) because they try to
ensure true names. (Still, that is true for PKI more than it is for
PGP, because it is *I* who decides who to trust and what key IDs mean.)
That may not be what email users need, so there may be a cheaper way of
ensuring "security" than this. I wonder why no-one has yet come up with
one?
The reason why nobody has come up with a fix to S/MIME is that the manufacturers believe in the PKI model, and won't listen to alternates. This is carried to ludicrous lengths, essentially, they believe that your relationship with Verisign is stronger than your relationship with your mother, and therefore you must be protected from a failure in this weak relationship.
PS: I find Enigmail integration into Thunderbird very painless and very
convenient.
I must try it!
iang

Message # 17

Date: Wed, 17 May 2006
From: "James A. Donald"
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
James A. Donald wrote:
Security should have near zero cost. It should come > > for free with contact list and alias management.
Stephan Neuhaus wrote:
To return to the question of email, I agree with you > that PGP et al. can incur significant cognitive > overheads (as it were) because they try to ensure true > names. (Still, that is true for PKI more than it is > for PGP, because it is *I* who decides who to trust > and what key IDs mean.) That may not be what email > users need, so there may be a cheaper way of ensuring > "security" than this. I wonder why no-one has yet > come up with one?
Compatibility with standards created in more trusting times is a big part of the problem.
Assume we have the luxury of redoing email and web standards from the beginning:
First, most scamming and phishing aims at stealing shared secrets such as passwords, credit card numbers and social security numbers. So first we replace the current practice where the client reveals the secret to the server, with SRP, where the client proves to the server he knows the secret, and the server proves to the client it knows the secret, without either revealing the secret to the other. (Actually SRP does better than that, but my description is close enough to the truth).
This requires that login and setting up a login needs to be in the browser chrome, or in something like Microsoft's Identity Metasystem.
All mail servers would generate a self signed root certificate, which can never change. This certificate is the root of a certificate chain which certifies the public key that the server uses, which may change. The default, however, is one level - the root key is the use key. All mail goes directly from the mail server of the sender to the mail server of the recipient - no forwarding.
When one mail server receives a message from another mail server whose key it has not yet cached, it gives the other a hard time. First it drops the connection, then it contacts the other through DNS to make sure that it is in fact possible for the other to receive messages. It then requires the the other to generate a hashcash token, and may also demand that it gets the human trying to send the message on the line to pass a turing test. It might also demand payment of actual money. If the server trying to send the message passes these requirements, its key gets cached, and subsequently it can send messages without all this hassle. The purpose of these tests is to ensure that setting up a new mail server is inconvenient and costly, so that getting a mail server blacklisted hurts.
The sending server, however, caches and whitelists the receiving server without giving it a hard time.
Messages between clients and servers are encrypted and authenticated using SRP. Thus the client knows he is talking to the correct server, and the server knows it is talking to the correct client, and that no one else is listening in, or has changed the message. Servers talk to each other using using their cached keys for encryption and authentication.
Of course, a weakness of this system is that encryption is not end to end. If either of the servers is suborned, you are hosed. Not a big problem if your adversary is a scammer, but a serious problem if your adversary is the fibbies.
To give it an end to end characteristic, each user provides his client encryption key, which by default is the same as his username with the server. (The default provides no security at all against a suborned server) A public private key pair is constructed using the encryption key, a server provided salt, the username, and the server DNS name. These public keys are cached by clients and used for end to end encryption and authentication against the cache.
This describes authenticated and secured messages between some completely random people. But such messages are seldom under attack. Most commonly, messages that are from a web site where one has login are under attack - for example messages purportedly from your bank or credit card company.
The system I described secures email addresses, but for commercial interaction, email addresses are too powerful. When one gives a web site a means to contact you, you do not want them to resell it to the entire world, and if they do resell it to the entire world, you want to be able to shut that means off. So you don't want to give your email address. You want to give an alias, which is not particularly human readable, and which your mail server knows should only be used by the mail server on that particular web site.
The handles to which eBay attaches reputations are weaker than email addresses, for you only get to see the email address corresponding to a handle if you *first* agree to an offered contract. Ideally, that email address should only function between parties to the contract, and should cease to function when the parties decide the contract has been completed. So when you see such a message, you know it is from the authentic party (unless the authentic party is playing footsie with spammers, in which case you turn it off.) When you give a web site the ability to contact you, it should function similarly. For credit card notifications, bank statements, and the like, we need something weaker than email addresses, so that we can be sure the message is really something the bank intended us to see, and not a fraud, and so that the bank cannot sell our address to ten million spammers.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
+Q+xt9NIx4zLv5OANX6yCPPbg/bQ6DvW5YVonuFK
4WsHAPDaohc+/MunR3q0d95Gdz9JOZMu03AZcD/3Y

Message # 18

Date: Wed, 17 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello James,
At 15/05/06 02:16, James A. Donald wrote:
--
Hagai Bar-El wrote:
What we tend to forget is that even though the "poorly
trained grunt soldier" matches the profile of most
users, the rule did not mean to apply to the colonels.
The fact that most people don't bother to switch
security on when having it as an option does not imply
that we should not bother building the system, or that
the system is insecure.
I observe that I continually receive genuine, but
unsigned, emails from banks that are under phishing
attacks, with "click here" links all over the place.
Your highly trained colonels appear to be AWOL.
Even Amazon, usually the epitome of good practice, keeps
sending out "please phish me" emails. The only
companies under phish attack that send out signed emails
are e-gold and pecunix - probably a result of their
cypherpunk backgrounds.
Ebay has adopted the non cryptographic practice of
(snip)
I was not saying that all e-mails that should be encrypted are encrypted. Many e-mails should be encrypted and/or signed and are not and the number of *these* is the indicator to whether or not e-mail security is a failure or not, not the *total* number of e-mails sent with no encryption.
Bank e-mails and e-mails concerning money should be encrypted and signed. If they are not - it's a bad point. The e-mails from my CFO must be encrypted, and they are, but when he uses his PDA he omits encryption - and this is another pad point. There are several like that, sent by both "colonels" and "soldiers", and these are indicative of some inadequacy of the system, I agree. I only claim that this is is the measure we should use, rather than the overall acceptance of e-mail encryption for the masses.
Any system where it is easy enough to encrypt what needs
to be encrypted, would be easier if it encrypted them
all. SSH does not support a readily accessible
unencrypted mode, not because they wanted to force the
great unwashed masses to use encryption, but because
more options means more work for the user. To give the
masses easy access to what they need, they relegated
what was not needed to be less accessible. Who needs
unencrypted mode?
I agree. When secure-only modes can be done they should. So is the case for Skype. In-secure modes should only be supported when there is no choice or when the cost is high for the user and does not always need it. This is not the case for SSH and for Skype.
Take a P2P (hence, non-server-based) system that
secures IRC messages using either PKI or symmetric
keys. For the purpose of actually activating this, the
user has to generate a key and negotiate it with each
and every peer he corresponds with.
No he does not. His client does.
Right, but for this to be really useful, some real identity should be set behind the client. Also, a Skype-like model requires a central trusted server to initially bind names to keys. An SSH-model would work, but still omits the actual user identity from the security model. Sometimes it's good enough - something it's not. For example - if the communication is one-time in nature then trusting the key once and caching it does not add much.
Hagai.

Message # 19

Date: Wed, 17 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello James,
At 15/05/06 02:16, James A. Donald wrote:
--
Hagai Bar-El wrote:
What we tend to forget is that even though the "poorly
trained grunt soldier" matches the profile of most
users, the rule did not mean to apply to the colonels.
The fact that most people don't bother to switch
security on when having it as an option does not imply
that we should not bother building the system, or that
the system is insecure.
I observe that I continually receive genuine, but
unsigned, emails from banks that are under phishing
attacks, with "click here" links all over the place.
Your highly trained colonels appear to be AWOL.
Even Amazon, usually the epitome of good practice, keeps
sending out "please phish me" emails. The only
companies under phish attack that send out signed emails
are e-gold and pecunix - probably a result of their
cypherpunk backgrounds.
Ebay has adopted the non cryptographic practice of
(snip)
I was not saying that all e-mails that should be encrypted are encrypted. Many e-mails should be encrypted and/or signed and are not and the number of *these* is the indicator to whether or not e-mail security is a failure or not, not the *total* number of e-mails sent with no encryption.
Bank e-mails and e-mails concerning money should be encrypted and signed. If they are not - it's a bad point. The e-mails from my CFO must be encrypted, and they are, but when he uses his PDA he omits encryption - and this is another pad point. There are several like that, sent by both "colonels" and "soldiers", and these are indicative of some inadequacy of the system, I agree. I only claim that this is is the measure we should use, rather than the overall acceptance of e-mail encryption for the masses.
Any system where it is easy enough to encrypt what needs
to be encrypted, would be easier if it encrypted them
all. SSH does not support a readily accessible
unencrypted mode, not because they wanted to force the
great unwashed masses to use encryption, but because
more options means more work for the user. To give the
masses easy access to what they need, they relegated
what was not needed to be less accessible. Who needs
unencrypted mode?
I agree. When secure-only modes can be done they should. So is the case for Skype. In-secure modes should only be supported when there is no choice or when the cost is high for the user and does not always need it. This is not the case for SSH and for Skype.
Take a P2P (hence, non-server-based) system that
secures IRC messages using either PKI or symmetric
keys. For the purpose of actually activating this, the
user has to generate a key and negotiate it with each
and every peer he corresponds with.
No he does not. His client does.
Right, but for this to be really useful, some real identity should be set behind the client. Also, a Skype-like model requires a central trusted server to initially bind names to keys. An SSH-model would work, but still omits the actual user identity from the security model. Sometimes it's good enough - something it's not. For example - if the communication is one-time in nature then trusting the key once and caching it does not add much.
Hagai.

Message # 20

Date: Thu, 18 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
Ian G wrote:
This is the old "SSH flaw" - in theory anyone can do > an MITM on the first setup. SSH said, "well, that's > too expensive to cover so we won't." That statement > is well known ... what is much less well known is that > the threat of the MITM is very low risk.
MITM on the first setup is very low risk, because on first setup, there is not much worth stealing, and because there are not that many first setups.
MITM in general is quite high risk - all phishing attacks are man in the middle attacks, and there is also quite a bit of DNS poisoning and proxy cache poisoning, which are also man in the middle attacks.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
F7qqPR/L4NcfheF+lU3TXUA+EOvASIA2537CNGPG
4IuVc3A1lAqF3M6fE8GkRJ5fuoZaad0DxGYSoiocV

Message # 21

Date: Thu, 18 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

James A. Donald wrote:
--
Ian G wrote:
This is the old "SSH flaw" - in theory anyone can do
an MITM on the first setup. SSH said, "well, that's
too expensive to cover so we won't." That statement
is well known ... what is much less well known is that
the threat of the MITM is very low risk.
MITM on the first setup is very low risk, because on
first setup, there is not much worth stealing, and
because there are not that many first setups.
Right. This is why online banking is a close match for this technique. In the first instance there is no value, no account. Only later on is there some value to steal.
Which is an example of assumptions failure from mission creep. Originally, SSL (v2) was predicated on the user having no relationship with the server.
And therefore needing the cert from a "TTP" to provide that relationship. This was the purported "ecommerce" mission, where a user surfed and found a random site selling something.
In online banking this is flipped around - the user has a strong relationship with her bank, and generally much stronger than any "TTP" can provide.
Hence, SSL (v2 and later) PKI is a bad fit for online banking, hence, phishing.
MITM in general is quite high risk - all phishing
attacks are man in the middle attacks, and there is also
quite a bit of DNS poisoning and proxy cache poisoning,
which are also man in the middle attacks.
Yes - I perhaps should have differentiated between the various forms of MITM. Phishing is in general a bypass MITM. It bypasses the security system completely (classically). Lower layer poisoning attacks achieve the same thing.
Then there is a second class of MITM - the PKI MITM.
Here, a valid certificate is acquired by breaching the CAs. Easy to do if you know how to take over people's email accounts and their credit cards.
And finally there is the in-protocol MITM. It was this that primarily attracted the cryptographers to the CA design. Arguably, this is killed dead, but has shifted the burden from a simple technical scope to a large and complex governance scope. So it is not clear that the overall equation results in net positive benefit.
The essence here is that the MITM was claimed to be defeated. But it was only the last one that was defeated, at a cost of opening up the second one, and at a further cost of a false sense of security against the first one.
(And, to try and close this confusing story, it was the latter that I was claiming was low risk.)
iang

Message # 22

Date: Thu, 18 May 2006
From: coderman
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

On 5/17/06, James A. Donald wrote:
...
MITM in general is quite high risk
particularly over wireless networks. especially at conferences and other venues where targets congregate...

Message # 23

Date: Thu, 18 May 2006
From: Ian G
To: coderman
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

coderman wrote:
On 5/17/06, James A. Donald wrote:
...
MITM in general is quite high risk
particularly over wireless networks. especially at conferences and
other venues where targets congregate...
The possibility is ... plausible. The risk is another matter.
Is there any evidence yet of wireless MITMs for gain?
I've never seen any, although the anecdotal reports have increased over the last few years.
(I generally discount techie conferences where "laboratory conditions" are assumed or prevail.
I also discount hacking into users' systems, as that's a system crack not an MITM. There is a bit more evidence that people are using open wireless to access business systems to steal data.)
iang

Message # 24

Date: Thu, 18 May 2006
From: coderman
To: "Ian G"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

On 5/18/06, Ian G wrote:
...
Is there any evidence yet of wireless MITMs for
gain?
i have seen these attacks* first hand for the purposes of: - ssh login interception for gathering zombies / shell accts / data.
- https MITM for spoofing credit credit payment forms (apparently people will indeed click right past cert warnings to pay for things).
- general ssl / tls password interception (ssh, https, other) for endorphins / t-shirts.
all but two instances i encountered working for a wireless ISP in PDX, so this is not a pandemic threat by any means. but it does occur and is getting more popular.
* this kind of wireless MITM has been called 'rogue AP', 'evil twin', and 'spoofed AP'. passive sniffing attacks are more common but easily avoided using encryption.
I've never seen any, although the anecdotal
reports have increased over the last few years.
i'd love to see a good analysis for various environments where wireless is popular.
(I generally discount techie conferences where
"laboratory conditions" are assumed or prevail.
fair enough. these kinds of attacks should be expected at security / hacker conferences i suppose.
I also discount hacking into users' systems, as
that's a system crack not an MITM.
i've seen a lot more of these exploit / penetrate attacks against users on the same wireless hotspot or within range of injection attacks.
There is a
bit more evidence that people are using open
wireless to access business systems to steal
data.)
this too, via active attacks. this is also more like a crack as mentioned above than a MITM.

Message # 25

Date: Thu, 18 May 2006
From: Stephan Neuhaus
To: Ian G
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Ian G wrote:
Is there any evidence yet of wireless MITMs for
gain?
German authorities are developing tools to capture IP traffic from suspected offenders using MITMs. It could even be that these tools are already in use.
Fun,
Stephan

Message # 26

Date: Fri, 19 May 2006
From: Ian G
To: Stephan Neuhaus
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

Stephan Neuhaus wrote:
Ian G wrote:
Is there any evidence yet of wireless MITMs for
gain?
German authorities are developing tools to capture IP traffic from
suspected offenders using MITMs. It could even be that these tools are
already in use.
Well, people have been *developing* things like this for decades. One could say that the whole PKI structure is "developed" for allowing MITMs for certain elect parties, especially if one follows the in's and out's... but I've never been able to find one of these cases where roots are used for MITMs (aside from the Chinese).
(The FBI has these too, but these aren't MITMs: https://www.financialcryptography.com/mt/archives/000476.html )
Facts rule.
We know that bypass-MITMs consume $1bn per annum in the US. This is a reasonably good statistic that has repeated itself over a 2-3 year stretch, it's good to within an order of magnitude. There are similar stats for Australia and UK.
We've got some view as to cert-MITMs now, something in the order of hundreds seen by end of 2005, but I have seen no reports of large losses from them so far.
Yet, nothing on protocol-MITMs. Not even lousy TCP connections are attacked in this way. On the one hand we know that this is tricky because the attacker has to be on the path so as to block and replace the packets. On the other hand, it is simply more economic to do a bypass attack coz we get thousands in one attack, or to crack thru a weakness in the endpoints.
The protocol-MITM is a bogeyman that has been used to justify all sorts of nonsense - yet we still have no viable statistics on actual use in the wild. Meanwhile, the phishing style bypass-MITM has reliable losses in the order of a billion, and everyone pretends it is someone else's problem.
What's up with that?
As a point of science, I claim the protocol-MITM is no risk. Security should be proportional to risk, so it is not one worth protecting against the protocol-MITM it it costs you anything.
Let's figure out the risk of a protocol-MITM - which I call zero (a.k.a., below measurable).
Shouldn't be too hard :)
iang

Message # 27

Date: Fri, 19 May 2006
From: Ian G
To: PracticalSecurity at hbarel.com
Subject: [PracticalSecurity] The rare MITM

How far do we have to go? Radio station in Long Island, USA.
WBAB offers $10K reward for radio hijacker http://www.newsday.com/news/local/longisland/ny-liwbab0519,0,5192460.story?coll=ny-editorials-headlines
....
John Shea, the station's general manager, said the hacker used an illegal transmitter and a small antenna to intercept the high frequency microwave signal the station sends between its studios in Babylon and its transmitting tower 6 miles away in Dix Hills.
Luce said that when a Pink Floyd song was replaced suddenly by static Monday morning, he initially thought it might have been the weather playing havoc. Then, when the country and western-style song came on, he thought a Rhode Island station might have been overlapping with WBAB.
When he heard the song's lyrics, he said he knew they'd been hijacked. He and Parise tried to turn off the transmitter, but couldn't because the hacker had taken over the signal, Shea said. The station regained control when the hacker cut out.
"I've been in this business 26 years," Shea said, "and it's the first time I've seen it."

Message # 28

Date: Fri, 19 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello,
At 16/05/06 02:20, James A. Donald wrote:
--
Hagai Bar-El:
for this to be really useful, some real identity
should be set behind the client.
But "real" identity is not useful, for there are no true
names, only true relationships. PKI is burdensome
because we do not, in fact, want to use true names.
Supposedly e-gold is not the true name of e-gold - at
least that is what one discovers when one delves deeply
enough into official truth.
Also, a Skype-like model requires a central trusted
server to initially bind names to keys. An SSH-model
would work, but still omits the actual user identity
from the security model.
People trust nyms, not identities. What is a brand name
but a nym?
I agree that "real names" are not needed and perhaps are too cumbersome for their limited added benefit here. However, when I was discussing "real names" I was not referring necessarily to ID-style nationwide (or worldwide) identifiers but rather to some nym which (from the users perspective) is bound to some identity outside the scope of the system, which the user already trusts.
In many cases, if the web session is with identity XYZ and the initial enrollment session was carried out during a session with XYZ then the trust was established during the enrollment, and nothing else is needed just like what SSH does.
However, in some cases, the initial enrollment is not a trust bootstrapper for itself, and needs to itself be trusted. In this case, the SSH model no longer holds. What the user needs is some link to an external trusted identifier, which can sometimes be, but not necessarily, the legal name of the entity. The user does not care that he's talking with "Outpost merchandise limited", or whatever but that it's "that Fry's shop I visited on the way to the airport". He does not mind what name the security association carries - he minds that this identity links to someone he knows. The CA model does an approximation for that, although I admit that not with much success.
If it was customary for businesses to publish their public key fingerprint on their printed collateral, newspaper ads, etc. it could solve the problem. Key revocation would become a nightmare, though.
What we really need is true relationship tracking: We
need our client to tell us that this communication
really does from xxxxx at xxxxxx.xxx, whom we previously
posted to. This other communication really does come
from the web site xxxxxxx.com, with which I created a
login, and the click to login links are provided by my
client, or at least blessed by my client, not the html
in the email. PKI is not necessary for this, not
particularly useful for this.
In some cases, linking to the initial enrollment process is good enough. In other cases the enrollment process itself needs to be linked to something else...
Sometimes it's good enough - something it's not. For
example - if the communication is one-time in nature
then trusting the key once and caching it does not add
much.
What we urgently need to protect are communications from
our banks, employers, credit card companies, Amazon, and
ebay - none of which are "one time"
Banks and credit card companies are indeed not one-time, but they do not and will not adopt an SSH-style "relationship tracking" either.
Not even a single bank I know will just provision you with a key on the first time you login to enroll and recognize you thereafter using this key. Enrollment is always involving an out-of-band binding to some other "trusted" identity. Authentication during enrollment is typically based on some credential that you get on a slip of paper at the branch, where you were authenticated by more "physical" means.
Amazon is actually an example for a "one-time", given you don't have a withstanding relationship (hence, an account) with them. I visit amazon.com, I buy a book, I give my credit card information, and I do not want or plan to hear of Amazon ever again. I need to trust the connection on this first-time visit, and I don't find it necessary to cache this key for future use.
Again, as you pointed out, a cryptic business entity name, as the one on the certificate, does not help me, but an implicit trust due to past transactions will not help me either, because there were none.
What I need is indeed a nym, but one that links to an entity I trust already, possibly by means that are external to the system. What I need is a way to know that I am connecting to "this Ama-something store that all my friends are getting all their books at".
Certificates don't help me much here, and implicit trust by linking to past transactions or to enrollment does not help me yet either.
If a communication is truly one time in nature, there is
little incentive for a man in the middle attack, so
certification does not add much. I am not going to do
business with e-gold because Verisign says it is owned
by Gold and Silver reserve. I am going to do business
with e-gold because other people do - I want to access
the same entity that Joe Random accessed. A full
Zooko's triangle system would handle that considerably
better than PKI does.
I am not too much aware of Zokoo's triangle system, but will gladly look into it. Thanks for pointing it out.
Hagai.

Message # 29

Date: Fri, 19 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello,
At 16/05/06 14:35, Ian G wrote:
Hagai Bar-El wrote:
The fact that most people don't bother to switch
security on when having it as an option does not imply that we should
not bother building the system, or that the system is insecure.
System's security is measured to the light of a threat model. If the
threat model is such that indicates a threat only in 1% of the cases the
system is used then having security switched on 1% of the times (given
it's the matching 1%) does not make the system insecure.
99.9% of the e-mails are not encrypted, but to see this as a failure of
the system we need to discuss how many of the e-mail should have been
encrypted was the system designed and running properly. Of course, it
never hurts to encrypt all, but to judge that a system is insecure just
because security is often left off we need to actually see how many
"misses" we had, that is, cases in which security was supposed to be
turned on, yet was not.
I think I mildly disagree with that hypothesis,
but I'm not sure how to prove it one way or
another. And that may be the problem - how do
you develop an acceptable rate of encrypting
the right messages?
I am not sure there is an easy way to determine the "total damage caused by not encrypting e-mail that was supposed to be encrypted, due to factors that are dependent on the crypto-system". It is indeed impossible to determine. There are many open questions here, such as of damage quantification and such as determining why e-mail was not encrypted. However, I state that as this is the case, we cannot determine that e-mail encryption has just failed for superficial reasons such as "most people don't use it".
I am personally fond of e-mail security, but I can also understand where some people come from when they claim that all the fuss about e-mail encryption is probably just marketing spins of e-mail encryption products vendors, because, apparently, most people do not encrypt their e-mails, many corporate users also don't, and evidently you do not hear of too many severe incidents in which tapped corporate e-mail has caused significant losses to anyone.
In a sense, we would have to look at the threat
scenarios for say email. For the most part, our
best evidence of this is things like discovery
in legal cases (not because crypto would have
saved them but it gives a guide to the quality
of a sensitive versus insensitive email).
There, I would hazard a guess that it is hard to
predict in advance which email would become the
smoking gun. The closer we get to defining it,
the more it seems that we should just not do any
(snip)
Right, but the risk here is different, as you pointed out. The risk in this case is from the actual communication with the valid party, not a result of an attack by an adversary. This is some problem you have with any logged communication, and encryption could not help you out. All these e-mails, that can perhaps get you in legal mess, are still not sensitive according to the threat model that e-mail encryption addresses.
I agree, and always had, that systems that are made for the public
and/or that can easily be built with one mode (e.g. Skype) should be
built that way, I am not arguing on this, but the fact that a system has
security as an option does not for itself make it insecure.
No, it doesn't make it insecure, but it does mean
we are now in the realm of assumptions. The
security model is now complete only if certain
user assumptions are met - that is, the user has
indeed turned on security for the important message.
I agree, but I would prefer that we do not see the "realm of assumptions" as B/W. We were in the realm of assumptions all along, also with Skype, when we assumed that the user chose a strong password.
I agree that Skype gives a much better than zero security for zero cost, and I thus agree that it forms a good deal. I was just pointing out that "automatic-security" is not always possible. E-mail is an example for where automatic security is much harder to introduce.
(It would be apropos at this point to bring in an
example where there are significant costs, and the
user must be given a choice.)
Take a P2P (hence, non-server-based) system that secures IRC messages
using either PKI or symmetric keys. For the purpose of actually
activating this, the user has to generate a key and negotiate it with
each and every peer he corresponds with. Although such a secure system
can be very useful in some cases, it would not be reasonable to force
the user into encrypting each and every session with each and every
peer, e.g. by forcing a prompt for a key before the first message in a
session goes out. The user should be able to decide that this particular
exchange needs not be secure as opposed to some other exchanges which must.
Well, I would simply exchange the public keys as
part of the protocol and use them. Create a sense
of key-relationship, by recording how many times it
is seen. Allow external verification.
You can do it, but it will not protect against even the slightest MITM attack. The user may be trained to detect it by watching the counters, but this is probably even harder to expect the user to do.
It also assumes the initial session is secure.
When I chat about tea recipes with someone I don't know over IRC in a
tea-lovers forum, I would not like to be forced to call him on the phone
and negotiate keys. When I communicate with the office over a public
WLAN when I am abroad, I am happy to do this key negotiation and know
that I can chat freely about sensitive stuff.
Right. But that proposal is based on a sense
that only a voice-confirmed key is worth it in
our security model.
Not necessarily voice. Any out of band would do. Actually, any in-band could do as well, as long as it utilizes some pre-existent anchor that is already trusted. Voice confirmation was just an example.
However, trusting a key just because this is the key you saw before is not always suitable.
I agree that security comes for no cost at most times, and thus there is
no motivation for insecure modes, but I claim that this is so only when
you can assume the key management infrastructure to be pre-existent.
When registered keys are not there yet, and given there is no world-wide
repository in which everyone is enrolled automatically, this is far from
being "no-cost security".
In some systems always-secure is easy - in some systems it's not...
Well, true. It is important to define our
user base. I generally assume for sake of
argument the average Internet application,
including those things known as ecommerce.
If security only marginally matters, then Skype-like systems are great. It's much more than nothing and comes at no cost. However, for the more security-demanding applications I believe that a more careful key management is required, even at the cost of damaging automation.
I generally reject esoterica such as national
security, not because it is a "demanding"
field but because there is too much money
and agenda washing around, so it isn't worth
the bother to argue through it.
I agree. :)
In contrast, on the net, people are generally
very grateful for security that comes at next
to no cost. E.g., Skype. They don't bring
up strawmen arguments like the security model
is not CC confirmed (as a hypothetical argument),
they just use it.
Right, but this is because they do not care about security anyway. I am sure that 99% of the Skype users would have used Skype even if it had no security at all. People (and companies) that care about security don't use Skype, and they have good reasons not to. I am also quite sure that even you don't use Skype, out of the box, for your "secure messaging" needs.
So the question here is - is there a user base
where we need to involve those up front costs
that make security hard? Or can we simply
assume that all users will be adequately
served by opportunistic startup, and an option
later to go to "voice-confirmed" mode?
(I argue the latter, of course.)
I agree. Skype gives a good starting point, and e-mail gives zero.
Yet, security needs to be measured by where it is needed, and where it is actually needed there are often very few shortcuts. I am not saying that voice confirmation is the only way, but some adequate key management is needed, and this is hard to give for plain zero cost.
Hagai.

Message # 30

Date: Fri, 19 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello,
At 16/05/06 02:20, James A. Donald wrote:
--
Hagai Bar-El:
for this to be really useful, some real identity
should be set behind the client.
But "real" identity is not useful, for there are no true
names, only true relationships. PKI is burdensome
because we do not, in fact, want to use true names.
Supposedly e-gold is not the true name of e-gold - at
least that is what one discovers when one delves deeply
enough into official truth.
Also, a Skype-like model requires a central trusted
server to initially bind names to keys. An SSH-model
would work, but still omits the actual user identity
from the security model.
People trust nyms, not identities. What is a brand name
but a nym?
I agree that "real names" are not needed and perhaps are too cumbersome for their limited added benefit here. However, when I was discussing "real names" I was not referring necessarily to ID-style nationwide (or worldwide) identifiers but rather to some nym which (from the users perspective) is bound to some identity outside the scope of the system, which the user already trusts.
In many cases, if the web session is with identity XYZ and the initial enrollment session was carried out during a session with XYZ then the trust was established during the enrollment, and nothing else is needed just like what SSH does.
However, in some cases, the initial enrollment is not a trust bootstrapper for itself, and needs to itself be trusted. In this case, the SSH model no longer holds. What the user needs is some link to an external trusted identifier, which can sometimes be, but not necessarily, the legal name of the entity. The user does not care that he's talking with "Outpost merchandise limited", or whatever but that it's "that Fry's shop I visited on the way to the airport". He does not mind what name the security association carries - he minds that this identity links to someone he knows. The CA model does an approximation for that, although I admit that not with much success.
If it was customary for businesses to publish their public key fingerprint on their printed collateral, newspaper ads, etc. it could solve the problem. Key revocation would become a nightmare, though.
What we really need is true relationship tracking: We
need our client to tell us that this communication
really does from xxxxx at xxxxxx.xxx, whom we previously
posted to. This other communication really does come
from the web site xxxxxxx.com, with which I created a
login, and the click to login links are provided by my
client, or at least blessed by my client, not the html
in the email. PKI is not necessary for this, not
particularly useful for this.
In some cases, linking to the initial enrollment process is good enough. In other cases the enrollment process itself needs to be linked to something else...
Sometimes it's good enough - something it's not. For
example - if the communication is one-time in nature
then trusting the key once and caching it does not add
much.
What we urgently need to protect are communications from
our banks, employers, credit card companies, Amazon, and
ebay - none of which are "one time"
Banks and credit card companies are indeed not one-time, but they do not and will not adopt an SSH-style "relationship tracking" either.
Not even a single bank I know will just provision you with a key on the first time you login to enroll and recognize you thereafter using this key. Enrollment is always involving an out-of-band binding to some other "trusted" identity. Authentication during enrollment is typically based on some credential that you get on a slip of paper at the branch, where you were authenticated by more "physical" means.
Amazon is actually an example for a "one-time", given you don't have a withstanding relationship (hence, an account) with them. I visit amazon.com, I buy a book, I give my credit card information, and I do not want or plan to hear of Amazon ever again. I need to trust the connection on this first-time visit, and I don't find it necessary to cache this key for future use.
Again, as you pointed out, a cryptic business entity name, as the one on the certificate, does not help me, but an implicit trust due to past transactions will not help me either, because there were none.
What I need is indeed a nym, but one that links to an entity I trust already, possibly by means that are external to the system. What I need is a way to know that I am connecting to "this Ama-something store that all my friends are getting all their books at".
Certificates don't help me much here, and implicit trust by linking to past transactions or to enrollment does not help me yet either.
If a communication is truly one time in nature, there is
little incentive for a man in the middle attack, so
certification does not add much. I am not going to do
business with e-gold because Verisign says it is owned
by Gold and Silver reserve. I am going to do business
with e-gold because other people do - I want to access
the same entity that Joe Random accessed. A full
Zooko's triangle system would handle that considerably
better than PKI does.
I am not too much aware of Zokoo's triangle system, but will gladly look into it. Thanks for pointing it out.
Hagai.

Message # 31

Date: Fri, 19 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?
Cc: practicalsecurity at hbarel.com

Hello,
At 16/05/06 14:35, Ian G wrote:
Hagai Bar-El wrote:
The fact that most people don't bother to switch
security on when having it as an option does not imply that we should
not bother building the system, or that the system is insecure.
System's security is measured to the light of a threat model. If the
threat model is such that indicates a threat only in 1% of the cases the
system is used then having security switched on 1% of the times (given
it's the matching 1%) does not make the system insecure.
99.9% of the e-mails are not encrypted, but to see this as a failure of
the system we need to discuss how many of the e-mail should have been
encrypted was the system designed and running properly. Of course, it
never hurts to encrypt all, but to judge that a system is insecure just
because security is often left off we need to actually see how many
"misses" we had, that is, cases in which security was supposed to be
turned on, yet was not.
I think I mildly disagree with that hypothesis,
but I'm not sure how to prove it one way or
another. And that may be the problem - how do
you develop an acceptable rate of encrypting
the right messages?
I am not sure there is an easy way to determine the "total damage caused by not encrypting e-mail that was supposed to be encrypted, due to factors that are dependent on the crypto-system". It is indeed impossible to determine. There are many open questions here, such as of damage quantification and such as determining why e-mail was not encrypted. However, I state that as this is the case, we cannot determine that e-mail encryption has just failed for superficial reasons such as "most people don't use it".
I am personally fond of e-mail security, but I can also understand where some people come from when they claim that all the fuss about e-mail encryption is probably just marketing spins of e-mail encryption products vendors, because, apparently, most people do not encrypt their e-mails, many corporate users also don't, and evidently you do not hear of too many severe incidents in which tapped corporate e-mail has caused significant losses to anyone.
In a sense, we would have to look at the threat
scenarios for say email. For the most part, our
best evidence of this is things like discovery
in legal cases (not because crypto would have
saved them but it gives a guide to the quality
of a sensitive versus insensitive email).
There, I would hazard a guess that it is hard to
predict in advance which email would become the
smoking gun. The closer we get to defining it,
the more it seems that we should just not do any
(snip)
Right, but the risk here is different, as you pointed out. The risk in this case is from the actual communication with the valid party, not a result of an attack by an adversary. This is some problem you have with any logged communication, and encryption could not help you out. All these e-mails, that can perhaps get you in legal mess, are still not sensitive according to the threat model that e-mail encryption addresses.
I agree, and always had, that systems that are made for the public
and/or that can easily be built with one mode (e.g. Skype) should be
built that way, I am not arguing on this, but the fact that a system has
security as an option does not for itself make it insecure.
No, it doesn't make it insecure, but it does mean
we are now in the realm of assumptions. The
security model is now complete only if certain
user assumptions are met - that is, the user has
indeed turned on security for the important message.
I agree, but I would prefer that we do not see the "realm of assumptions" as B/W. We were in the realm of assumptions all along, also with Skype, when we assumed that the user chose a strong password.
I agree that Skype gives a much better than zero security for zero cost, and I thus agree that it forms a good deal. I was just pointing out that "automatic-security" is not always possible. E-mail is an example for where automatic security is much harder to introduce.
(It would be apropos at this point to bring in an
example where there are significant costs, and the
user must be given a choice.)
Take a P2P (hence, non-server-based) system that secures IRC messages
using either PKI or symmetric keys. For the purpose of actually
activating this, the user has to generate a key and negotiate it with
each and every peer he corresponds with. Although such a secure system
can be very useful in some cases, it would not be reasonable to force
the user into encrypting each and every session with each and every
peer, e.g. by forcing a prompt for a key before the first message in a
session goes out. The user should be able to decide that this particular
exchange needs not be secure as opposed to some other exchanges which must.
Well, I would simply exchange the public keys as
part of the protocol and use them. Create a sense
of key-relationship, by recording how many times it
is seen. Allow external verification.
You can do it, but it will not protect against even the slightest MITM attack. The user may be trained to detect it by watching the counters, but this is probably even harder to expect the user to do.
It also assumes the initial session is secure.
When I chat about tea recipes with someone I don't know over IRC in a
tea-lovers forum, I would not like to be forced to call him on the phone
and negotiate keys. When I communicate with the office over a public
WLAN when I am abroad, I am happy to do this key negotiation and know
that I can chat freely about sensitive stuff.
Right. But that proposal is based on a sense
that only a voice-confirmed key is worth it in
our security model.
Not necessarily voice. Any out of band would do. Actually, any in-band could do as well, as long as it utilizes some pre-existent anchor that is already trusted. Voice confirmation was just an example.
However, trusting a key just because this is the key you saw before is not always suitable.
I agree that security comes for no cost at most times, and thus there is
no motivation for insecure modes, but I claim that this is so only when
you can assume the key management infrastructure to be pre-existent.
When registered keys are not there yet, and given there is no world-wide
repository in which everyone is enrolled automatically, this is far from
being "no-cost security".
In some systems always-secure is easy - in some systems it's not...
Well, true. It is important to define our
user base. I generally assume for sake of
argument the average Internet application,
including those things known as ecommerce.
If security only marginally matters, then Skype-like systems are great. It's much more than nothing and comes at no cost. However, for the more security-demanding applications I believe that a more careful key management is required, even at the cost of damaging automation.
I generally reject esoterica such as national
security, not because it is a "demanding"
field but because there is too much money
and agenda washing around, so it isn't worth
the bother to argue through it.
I agree. :)
In contrast, on the net, people are generally
very grateful for security that comes at next
to no cost. E.g., Skype. They don't bring
up strawmen arguments like the security model
is not CC confirmed (as a hypothetical argument),
they just use it.
Right, but this is because they do not care about security anyway. I am sure that 99% of the Skype users would have used Skype even if it had no security at all. People (and companies) that care about security don't use Skype, and they have good reasons not to. I am also quite sure that even you don't use Skype, out of the box, for your "secure messaging" needs.
So the question here is - is there a user base
where we need to involve those up front costs
that make security hard? Or can we simply
assume that all users will be adequately
served by opportunistic startup, and an option
later to go to "voice-confirmed" mode?
(I argue the latter, of course.)
I agree. Skype gives a good starting point, and e-mail gives zero.
Yet, security needs to be measured by where it is needed, and where it is actually needed there are often very few shortcuts. I am not saying that voice confirmation is the only way, but some adequate key management is needed, and this is hard to give for plain zero cost.
Hagai.

Message # 32

Date: Fri, 19 May 2006
From: coderman
To: "Ian G"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

On 5/19/06, Ian G wrote:
...
We know that bypass-MITMs consume $1bn per annum in
the US. This is a reasonably good statistic that
has repeated itself over a 2-3 year stretch, it's
good to within an order of magnitude. There are
similar stats for Australia and UK.
good usability is hard. secure usability is hard squared. :)
... or to crack thru
a weakness in the endpoints.
weak endpoints are a huge problem. the rootkits are getting nasty, reaching into userspace to snarf user input before it hits the protected SSL path, logging keystrokes, etc. i think this is on par with phishing style attacks although i don't know how prevalent.
certainly much more than protocol-MITM like you assert.
(the massive debit card and pin theft earlier this year is my favorite example of this to date, though it involved both insecure configuration (tracing enabled?) in addition to the exploit of POS terminals to capture the data. oops!)
The protocol-MITM is a bogeyman that has been
used to justify all sorts of nonsense - yet we
still have no viable statistics on actual use
in the wild.
it's probably the hardest path. i suspect if you close the phishing holes and harden the endpoints it would suddenly become much more popular.
phishing and exploits are the best investment by far because they are so easy and so effective.
Meanwhile, the phishing style
bypass-MITM has reliable losses in the order of
a billion, and everyone pretends it is someone
else's problem.
What's up with that?
too much focus on technical underpinnings and attachment to poor interfaces. the browser is horrible for secure user interaction but who will admit it is a lost cause?
As a point of science, I claim the protocol-MITM
is no risk. Security should be proportional to
risk, so it is not one worth protecting against
the protocol-MITM it it costs you anything.
as long as phishing and vulnerable endpoints exist i would agree.
over wireless i might argue the risk is non-zero but still very low.
i still insist this risk would increase greatly were you to solve the phishing and exploit vulnerabilities.

Message # 33

Date: Sun, 21 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Is E-mail encryption really too complex?

--
a cryptic business entity name, as the one on the > certificate, does not help me, but an implicit trust > due to past transactions will not help me either, > because there were none. What I need is indeed a nym, > but one that links to an entity I trust already, > possibly by means that are external to the system.
What I need is a way to know that I am connecting to > "this Ama-something store that all my friends are > getting all their books at".
What is needed is a reputation system as Ebay provides its users. Unfortunately Ebay reputations are kept on Ebay servers, and Ebay sellers are charged an arm and a leg for using them. Ebay reputations show how long someone has been doing business, how much business they have done, and a complete list of commendations and complaints by customers.
Netcraft provides, for free, a reputation system - necessarily less complete than Ebay's, but good enough to tell you if are on the real Amazon.com site. It detects most DNS cache poisoning and cross site scripting attacks, using heuristics rather than cryptographic security, and tells you how long the site has been in business, and how much traffic it sees from netcraft users.
Its main weakness is that if you are going to a seemingly familiar site, you are not likely to notice the flag saying probable scam site, since you tend to be focused on the task at hand.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
WWTCvOyLAcTjIoAxqjhvTcqZeegytFkggNG/9qDa
4a44wMByNdWKo5SsEVQW1eB+45nVQdUHZ09C36hBE

Message # 34

Date: Mon, 22 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: [PracticalSecurity] It is trivial to introduce secure email

Hagai Bar-El wrote:
E-mail is an example for
where automatic security is much harder to introduce.
Well, I disagree there :)
Introducing automatic encryption with
email is (I claim) trivial. It won't
happen of course, but it is trivial to
do. Here's how.
1. all email clients generate their
keys on demand.
2. public keys are sent at end of
emails.
3. public keys received are cached with the name in the address book.
4. auto-encryption to those emails where the keys are cached.
5. show the fingerprint of the key on
the chrome.
END OF STORY. The funny thing is that
almost all the code is already in place.
Now, people will attack that with all
sorts of strawmen like it is rampantly
open to breach by MITM. Such attacks
are just kneejerk reactions to the
discovery that there are different
ways to approach this problem - the
attacks have no founding.
In practice, in email, there is practically no risk of MITM. Where there is, do a key exchange. End of story.
What's the risk? Someone gets MITM'd. It would be like one in a million. What's the benefit? The million. These ratios speak for themselves, especially when compared to the benefits offered by S/MIME (tiny) and by PGP (slightly less tiny) where it is more like 1 in a thousand that gets the benefit.
iang

Message # 35

Date: Mon, 22 May 2006
From: coderman
To: "Ian G"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

On 5/22/06, Ian G wrote:
...
Introducing automatic encryption with
email is (I claim) trivial.
...
Now, people will attack that with all
sorts of strawmen like it is rampantly
open to breach by MITM.
but only if the initial exchange was MITM'd and cached Eve's bogus key.
Such attacks
are just kneejerk reactions to the
discovery that there are different
ways to approach this problem - the
attacks have no founding.
this would be awesome; please implement!
much much better than current state with almost zero risk.
What's the risk? Someone gets MITM'd.
how would you handle replacing deprecated keys that were lost, compromised, or expired in a similar trivial manner?
a new pubkey attached may be bogus (spoofed / MITM) or forged (if key was stolen) and you can't rely on a revocation signed by the previous key (it may be lost).

Message # 36

Date: Mon, 22 May 2006
From: Ian G
To: coderman
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

coderman wrote:
On 5/22/06, Ian G wrote:
...
Introducing automatic encryption with
email is (I claim) trivial.
...
Now, people will attack that with all
sorts of strawmen like it is rampantly
open to breach by MITM.
but only if the initial exchange was MITM'd and cached Eve's bogus key.
Right, silly risk really.
Such attacks
are just kneejerk reactions to the
discovery that there are different
ways to approach this problem - the
attacks have no founding.
this would be awesome; please implement!
much much better than current state with almost zero risk.
Well, I can't implement it :) It's so trivial, it's all there ... but the people who *own* the S/MIME applications and emailers don't subscribe to the vision. (Or at least, my experiences in discussing this with one application group, the Thunderbird people, have been unfruitful.)
So nice as it is, it isn't going to happen.
Sorry to get your hopes up!
What's the risk? Someone gets MITM'd.
how would you handle replacing deprecated keys that were lost,
compromised, or expired in a similar trivial manner?
Oh, I'm sure they will think of something.
I've been using PGP for over 10 years now, and it's not been an issue, you just burn your current setup and start again. People - users - are used to re-installing everything, they don't want or need or expect perfection, no matter how much they complain.
a new pubkey attached may be bogus (spoofed / MITM) or forged (if key
was stolen) and you can't rely on a revocation signed by the previous
key (it may be lost).
Yeah, minor problem.
iang

Message # 37

Date: Tue, 23 May 2006
From: "James A. Donald"
To: coderman
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
coderman wrote:
how would you handle replacing deprecated keys that > were lost, compromised, or expired in a similar > trivial manner?
Just start over.
Suppose Ann and Bob are communicating. Bob moves to a new computer, so his key changes. An email is lost.
They sort it out, perhaps in subsequent emails, perhaps out of band. Same thing happens with SSH. It is uncommon, and not a problem.
Of course Malloc could launch a conversation, pretending to be Bob with a key change, but that is a social engineering attack, requires considerable knowledge of your targets. It raises the bar, cannot be done routinely, or on a mass scale. If Bob's key changes one would probably not be very alarmed. If the BankOfAmerica's key changes, one would likely take notice.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
hQndj16rnPxKQBlBcWI1BnpJOxE9fcZTVW5abtWh
4lKV1w6Gzx1kS2RevMOIBkw0IZd87mNZkAG4QLrLm

Message # 38

Date: Tue, 23 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

Hagai Bar-El wrote:
Hello,
At 22/05/06 17:21, Ian G wrote:
1. all email clients generate their
keys on demand.
2. public keys are sent at end of
emails.
3. public keys received are cached with
the name in the address book.
4. auto-encryption to those emails where
the keys are cached.
5. show the fingerprint of the key on
the chrome.
Disregarding MITM is a threat-model decision.
Yes, but better than that, it is a *risk management* decision.
Small risk which means small expected cost, by orders of magnitude.
Large benefit, because much cheaper deployment, by orders of magnitude.
Orders of magnitude multipled by orders of magnitude :)
Clearly from your mail,
it's a risk you disregard, but some people will not, and they can come
up with very good explanations why MITM should not be disregarded for
e-mail, even if it generally could for other protocols.
a. There are truly very few circumstances where a usable MITM-vulnerable system is worse than an unusable MITM-resistant system. Kerchkoffs' 6th principle is his most important, IMO - the system must be usable under field conditions.
b. Above, there is point 5. For those who make a risk management decision that they are concerned with the MITM risk, they can simply phone up their other contact and do a key exchange over the phone, like as in PGP. The system covers the initial MITM threat - it just asks you to do the heavy lifting of the phone in the case where you need that.
c. You could make the case that there are people that need MITM protection but don't know it. I choose not to bother to protect those people, because if they don't know, then they will do something else which will compromise themselves, such as install windows. (Not because I'm being snarky or anything, just another risk management decision.)
d. You could make the case that people do know but won't do the phone-up MITM. Again, I choose not to make the phone call for them :)
e. Of course, if MITM was easy to solve, we would solve it in the code. It's just not easy to solve.
Luckily it is so rare and so "high value" that we can safely ignore it for the vast majority who fall in the "low value" threats class.
f. And, if one happens to fall, then he takes one for the team. His other choice was nothing, so he was still better off because he was protected for every other transaction. And we are all much better off.
MITM is difficult, but it's difficult when it's in real-time. E-mail
messages just lurk in your Internet-accessible mailbox for anything
between 5 minutes to five days until you pick them up. If you assume
that your opponent does not have the capability of breaking into your
POP mailbox then who exactly are you protecting yourself against?
Well, it is all about raising the bar. Are we agreed that the system substantially raises the bar?
Consider the MITM's attack. 1. he has to get access to the wire. That means he is either an insider, or he is mounting an active attack.
Which means the bar is already set a meter or two above the ground.
2. If the bar is high, we are then pushing him into other directions. So, we do not need to solve the MITM - we simply need to make it harder so that he attacks through the next available open area. As we know that the windows OS is like a wet paper bag when it comes to security, we don't need to shift the bar very high at all before the attacker goes for the OS attack.
3. If the attacker jumps the bar, then we find some people get hurt. Then we fix it.
BUT, it is far far FAR easier to fix an inplace system against a new threat than to fix a system that isn't there at all.
Of course, a casual lamer running Ethereal on his laptop in Starbucks
will be helpless against this scheme, but is this whom you're using PGP
(or alike) against?
(Hmmm... I'm not sure I follow ... do you mean that the "casual lamer" is the attacker or the defender?)
I agree that using your scheme will give something that is way above the
zero security that is granted today, but it is far off what people
expect when they actually turn to use encryption. For anyone seeking
"pretty good privacy" this will just provide a false sense of security,
I believe.
When they turn to use "high" security, they will read about part 5, and phone up their contacts.
It's just like PGP. I use PGP all the time...
But I don't bother to do a key exchange except once every 20 contacts, if that.
But *I know when I need to do it*. I don't expect PRZ to know when I need to do it. I don't expect to blame PRZ because he didn't fix it for me.
(And if I don't know, I'm still better off.)
PGP would have been far better off if they had eased off on all that key management stuff and said that it was for "advanced users only."
What's the risk? Someone gets MITM'd. It
would be like one in a million. What's the
benefit? The million.
But who is this one? This one would be the one who really needed
security, while the other million are the million messages that are not
even worth the wiretap and never needed security in the first place.
Who cares who is the one?
We aren't responsible for the one. The one didn't pay us. The one just wanted some basic security, and didn't get it. The one didn't read part 5.
It's a really stark choice:
1. we protect 999,999 people from most everything,
and 1 guy gets MITM'd.
2. we protect 1 guy and 9,999 get nothing.
(Choice 1 is even better ... when 1 guy gets MITM'd, he sets an example for all that follow. In choice 2, nobody follows.)
Again, I am not saying the scheme is not worth being used. I believe it
is, but we have to be very careful with who we aim it for and what
claims we make on it.
:-) No, it's completely the other way around. We simply say it does good crypto. It doesn't protect against everything, but there again, no scheme does.
What we shouldn't do is set some absolute target like "must cover MITM" and fail to meet it because the tool never gets used.
P.S. You would at least want to fix the situation in which the opponent
simply sends a single "Hi, what's up?" message with a fake "from"
address and his own key to his victim to get his own key registered for
any address. This is worse than a weak MITM - it's a weak race
condition... :)
Sure. Let's fix that after the first 100 users are out there.... Let's play around with some solutions.
The difference between SSH and SSLv2 is just that.
SSH was a fix for the password sniffing. SSLv2 was a fix for the MITM that didn't exist in SSLv1 (the cert-less variety). The difference was that SSH exists wherever we want it, and SSL exists only where we are so desperate we are out of business if we don't have it.
Never let a security flaw stop a security system from being deployed. If it isn't deployed, it is guaranteed to never protect users.
iang

Message # 39

Date: Wed, 24 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Ian G wrote:
1. all email clients generate their keys on demand.
2. public keys are sent at end of emails.
3. public keys received are cached with the name > in the address book.
4. auto-encryption to those emails where the > keys are cached.
5. show the fingerprint of the key on the chrome.
What you are describing is close to Crypto Kong built into the email client, Crypto Kong as Thunderbird extension, but with key fingerprints in place of Zooko's triangle.
Of course, as an extension, it is of limited value - network effects. Handier if everyone uses it, and those of them that do not need to use it don't know or care that they are using it. (Which would probably require encryption off by default, public keys and signature sent in header on by default.)
Crypto Kong was written back before we had a popular environment supporting extensions, and contains Zooko's triangle before it was so lucidly explained by Zooko.
Probably needs a total rewrite to move it to being an extension. Management of all those keys and the relationship of keys to identities and documents requires a fair bit of database code - the Crypto Kong database has five tables containing 24 fields linked by four relationships. Moving this to Thunderbird would require linking to its existing database of documents, and Thunderbird's existing database of documents and identities is not well documented to my knowledge.
(Neither is Crypto Kong's, but if anyone is interested, I will add it to the web documentation) The Crypto Kong database is complex in part because of the need to support what we now call Zooko's triangle.
Crypto Kong uses a signature to ensure message integrity of encrypted messages as well as to prevent MITM attacks. Without message integrity, its RC4 encryption would be vulnerable to substitution attacks. Universal signing is arguably a vulnerability, since it reduces deniability, but if your adversary has your emails, he probably has provenance of those emails, making denial difficult, and if his provenance for the emails is weak, his provenance for the nym is is weaker. Encryption without certificate authorities secures nyms, not true names. Thus universal signing of encrypted messages and default signing of plaintext messages is not particularly harmful, and provides protection against viruses and scams - at least you would know who's machine was infected.
To ensure authenticity of mail without signing - so that the recipient can prove it is authentic, but unpleasant people who have seized the backup of your email cannot prove it is authentic, requires we use a different protocol in place of email - an email like protocol layered on top of IM, or perhaps on top of VOIP, as SMS is layered on top of telephony.
Hostile people seizing central email records has proven to be a major and radical problem with email, and is a very serious concern for businesses, something they would pay serious money to remedy. A major reason for teleconferencing plus hand scribbled notes is to avoid the unnecessary multiplication of dangerous records.
Observe the ongoing confrontation with the courts by Microsoft and other deep pocketed companies over email records.
If the central corporate authority can set everyone's client to encrypt everything by default, and only decrypt on demand at the client computer, this considerably reduces the hazard from lawyers engaged in fishing expeditions. The fisher has to troll through each individual executive's computer, most of which, will, alas, have suffered a recent crash, and lack backups of critical data. The inconvenience of possibly losing data needs to be balanced against the convenience of possibly losing data at a convenient time.
Such an extension could be produced in two versions - for sale version with corporate friendly extensions, and an individual version for free so that people using the corporate version would be able to have secure conversations with anyone anywhere. (Not sure whether the Thunderbird license permits this - how viral is it?)
On the other hand, most businesses now use mail servers with a "lets not be too paranoid about keeping backups" mode, so perhaps it is not worth their while to switch to encryption. I have not been keeping track of the problem of lawyers trolling through emails looking for lawsuits - what remedies are corporations using these days? What is that market like? How are lawyers striking back? What do encryption based remedies provide that existing remedies fail to provide?
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
nnH0cy3ZFCDNN9dHiqNqC/fzlQT9S3SqVPq+dJ9J
4xbrdnPx6MBVWO4CQ4rIYTL7bLyLy/FBJ07hpg3tv

Message # 40

Date: Wed, 24 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Hagai Bar-El wrote:
Disregarding MITM is a threat-model decision. Clearly > from your mail, it's a risk you disregard, but some > people will not, and they can come up with very good > explanations why MITM should not be disregarded for > e-mail, even if it generally could for other > protocols.
The proposed system takes care of most forms of MITM. It is vulnerable to MITM on initial establishment of communications, which is not a problem because nothing much is at stake during initial establishment of communications, and there is usually some out of band reason for establishing communications that provides an authenticity check during initial establishment of communications.
For example if one establishes a login that involves an email address, the web site setting up the account will usually send you an expected email. Since the email is expected, cannot be forged, and establishes the keys.
Of course, a casual lamer running Ethereal on his > laptop in Starbucks will be helpless against this > scheme, but is this whom you're using PGP (or alike) > against?
More interestingly, the FBI and KGB will be helpless against this scheme.
Suppose I start conspiring with Ian to overthrow the state and the NSA, CIA, FBI, KGB, IRS and Mossad want to find out what we are saying. How are they going to use MITM to penetrate our emails if we are using this scheme?
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
9PnLY25Ea5eXnTOx2e52+r//AetfLmYweN/I+TMM
4qAnKCViArYhg2joSEf3vP7zL0HEzYoz57fHV3/5f

Message # 41

Date: Tue, 23 May 2006
From: coderman
To: "Ian G"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

On 5/22/06, Ian G wrote:
...
Well, I can't implement it :) It's so trivial,
it's all there ... but the people who *own* the
S/MIME applications and emailers don't subscribe
to the vision. (Or at least, my experiences in
discussing this with one application group, the
Thunderbird people, have been unfruitful.)
would it be useful to implement outside of the various applications in a manner similar to the off-the-record proxy as a route around stubborn developers?
(would you insert warnings and necessary fingerprints/signatures in headers / attachments similar to the way spam filters apply message ratings and such or would a full blown user interface for proxy interaction be needed?)
So nice as it is, it isn't going to happen.
Sorry to get your hopes up!
you bastard... :)
I've been using PGP for over 10 years now,
and it's not been an issue, you just burn
your current setup and start again.
sounds reasonable, and as James mentioned using this as an avenue for attack requires a social engineering angle even more difficult than the already complicated MITM needed to pull it off.

Message # 42

Date: Wed, 24 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello,
At 22/05/06 17:21, Ian G wrote:
Introducing automatic encryption with
email is (I claim) trivial. It won't
happen of course, but it is trivial to
do. Here's how.
1. all email clients generate their
keys on demand.
2. public keys are sent at end of
emails.
3. public keys received are cached with
the name in the address book.
4. auto-encryption to those emails where
the keys are cached.
5. show the fingerprint of the key on
the chrome.
END OF STORY. The funny thing is that
almost all the code is already in place.
(snip)
Disregarding MITM is a threat-model decision. Clearly from your mail, it's a risk you disregard, but some people will not, and they can come up with very good explanations why MITM should not be disregarded for e-mail, even if it generally could for other protocols.
MITM is difficult, but it's difficult when it's in real-time. E-mail messages just lurk in your Internet-accessible mailbox for anything between 5 minutes to five days until you pick them up. If you assume that your opponent does not have the capability of breaking into your POP mailbox then who exactly are you protecting yourself against?
Of course, a casual lamer running Ethereal on his laptop in Starbucks will be helpless against this scheme, but is this whom you're using PGP (or alike) against?
I agree that using your scheme will give something that is way above the zero security that is granted today, but it is far off what people expect when they actually turn to use encryption. For anyone seeking "pretty good privacy" this will just provide a false sense of security, I believe.
What's the risk? Someone gets MITM'd. It
would be like one in a million. What's the
benefit? The million.
But who is this one? This one would be the one who really needed security, while the other million are the million messages that are not even worth the wiretap and never needed security in the first place.
Again, I am not saying the scheme is not worth being used. I believe it is, but we have to be very careful with who we aim it for and what claims we make on it.
Hagai.
P.S. You would at least want to fix the situation in which the opponent simply sends a single "Hi, what's up?" message with a fake "from" address and his own key to his victim to get his own key registered for any address. This is worse than a weak MITM - it's a weak race condition... :)

Message # 43

Date: Wed, 24 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

James A. Donald wrote:
--
Ian G wrote:
1. all email clients generate their keys on demand.
2. public keys are sent at end of emails.
3. public keys received are cached with the name
in the address book.
4. auto-encryption to those emails where the
keys are cached.
5. show the fingerprint of the key on the chrome.
What you are describing is close to Crypto Kong built
into the email client, Crypto Kong as Thunderbird
extension, but with key fingerprints in place of Zooko's
triangle.
Right. Of course, what I describe is
hardly original, it is just basic crypto- plumbing from anyone who has done some
serious thinking, and has realised how
braindead some of the "popular solutions" are.
Of course, as an extension, it is of limited value -
network effects. Handier if everyone uses it, and those
of them that do not need to use it don't know or care
that they are using it. (Which would probably require
encryption off by default, public keys and signature
sent in header on by default.)
I'm curious - is Crypto Kong compatible with PGP or S/MIME? Wouldn't the network effects be more surmountable if it had
been so compatible?
Crypto Kong was written back before we had a popular
environment supporting extensions, and contains Zooko's
triangle before it was so lucidly explained by Zooko.
Yes.
Probably needs a total rewrite to move it to being an
extension. Management of all those keys and the
relationship of keys to identities and documents
requires a fair bit of database code - the Crypto Kong
database has five tables containing 24 fields linked by
four relationships. Moving this to Thunderbird would
require linking to its existing database of documents,
and Thunderbird's existing database of documents and
identities is not well documented to my knowledge.
(snip)
To be honest, I am also now wrestling with the decision to move much of my client software (for payments, not email) into a plugin environment.
There is an awful lot of luck in this business :)
Crypto Kong uses a signature to ensure message integrity
of encrypted messages as well as to prevent MITM
attacks. Without message integrity, its RC4 encryption
would be vulnerable to substitution attacks. Universal
signing is arguably a vulnerability, since it reduces
deniability, but if your adversary has your emails, he
probably has provenance of those emails, making denial
difficult, and if his provenance for the emails is weak,
his provenance for the nym is is weaker. Encryption
(snip)
Message integrity is pretty much expected these days. I don't think much of the "OTR" concept, as it clashes with what we know about court procedures - denying a message is a huge huge risk in court, and if OTR leads someone to deny a message in court, then that could really be serious.
OTOH, I do think it is best to declare up front that digsigs are not human sigs and have no legal intent.
To ensure authenticity of mail without signing - so that
the recipient can prove it is authentic, but unpleasant
people who have seized the backup of your email cannot
prove it is authentic, requires we use a different
protocol in place of email - an email like protocol
layered on top of IM, or perhaps on top of VOIP, as SMS
is layered on top of telephony.
I don't know that it is so important to prove authenticity. I think it falls in the "maybe" basket. The email system works quite well without it, so I'd definately propose thinking about it as an option, or a feature to be added on if desired.
Hostile people seizing central email records has proven
to be a major and radical problem with email, and is a
very serious concern for businesses, something they
would pay serious money to remedy. A major reason for
teleconferencing plus hand scribbled notes is to avoid
the unnecessary multiplication of dangerous records.
Observe the ongoing confrontation with the courts by
Microsoft and other deep pocketed companies over email
records.
Massive. The biggest risk for email is court discovery. By far. And it generally happens at the node - either yours, your opponents, or the company servers.
Encryption may help you protect at the company nodes. But protecting your node or your opponent's node remains a challenge.
If the central corporate authority can set everyone's
client to encrypt everything by default, and only
decrypt on demand at the client computer, this
considerably reduces the hazard from lawyers engaged in
fishing expeditions. The fisher has to troll through
each individual executive's computer, most of which,
will, alas, have suffered a recent crash, and lack
backups of critical data. The inconvenience of possibly
losing data needs to be balanced against the convenience
(snip)
Right.
Such an extension could be produced in two versions -
for sale version with corporate friendly extensions, and
an individual version for free so that people using the
corporate version would be able to have secure
conversations with anyone anywhere. (Not sure whether
the Thunderbird license permits this - how viral is it?)
Mozilla uses the Mozilla licence I think :) Not viral at all, just "return changes on a per file basis."
On the other hand, most businesses now use mail servers
with a "lets not be too paranoid about keeping backups"
mode, so perhaps it is not worth their while to switch
to encryption. I have not been keeping track of the
problem of lawyers trolling through emails looking for
lawsuits - what remedies are corporations using these
days? What is that market like? How are lawyers
striking back? What do encryption based remedies
provide that existing remedies fail to provide?
Well, the high value stuff is in areas like banking / finance / securities where all comms must be kept. That means all emails, all voice, all chat! So on the one hand they are fighting to keep it all, and on the other hand they are fighting to reduce the stuff kept.
So lots of money to be had if you can talk out both sides of your mouth :-)
iang

Message # 44

Date: Fri, 26 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Ian G:
I'm curious - is Crypto Kong compatible with PGP or > S/MIME?
No.
Wouldn't the network effects be more surmountable if > it had been so compatible?
Because it is not integrated with mail system, it necessarily passed everything in the body of the message, as people using PGP tend to do. SMIME can only be handled by something integrated with the mail system, and my gut feeling was and still is that PGP keys were too big and ugly to be routinely seen by human eyes.
It probably would have been wiser to produce a variant of PGP that discarded the web of trust, and replaced it with a database supporting what we now call Zooko's triangle, thereby avoiding network barriers to adoption, but it did not appear to me, and still does not appear to me, that PGP or SMIME had significant adoption. Don't think it was network barriers that did me in, for I was not aiming to compete in the rather small group of users that currently use PGP and SMIME. However, my analysis of downloads suggests that it had near zero impact outside that group of users - that Crypto Kong had near zero impact in its target market.
On the other hand, aiming for a broader customer base, should have made it an extension, but back then, did not much like any of the environments in which one could embed an extension.
Message integrity is pretty much expected these days.
I don't think much of the "OTR" concept, [deniable > message integrity] as it clashes with what we know > about court procedures - denying a message is a huge > huge risk in court, and if OTR leads someone to deny > a message in court, then that could really be serious.
OTOH, I do think it is best to declare up front that > digsigs are not human sigs and have no legal intent.
This works better if no specific action is involved, if message integrity is automatic, as in a plugin. OTR might be worth it where deniability can, in fact, be implemented, for example cryptographic IM, but so far not a single attack is known where deniable message integrity would have been any use, so it is hardly worth abandoning the email protocol for that reason, though there are many other more pressing reasons for a new protocol in place of email.
James A. Donald:
Hostile people seizing central email records has > > proven to be a major and radical problem with email, > > and is a very serious concern for businesses, > > something they would pay serious money to remedy. A > > major reason for teleconferencing plus hand > > scribbled notes is to avoid the unnecessary > > multiplication of dangerous records. Observe the > > ongoing confrontation with the courts by Microsoft > > and other deep pocketed companies over email > > records.
Ian G:
Massive. The biggest risk for email is court > discovery. By far. And it generally happens at the > node - either yours, your opponents, or the company > servers.
Encryption may help you protect at the company nodes.
But protecting your node or your opponent's node > remains a challenge.
Encryption protects at the company servers. I recall that in the most famous case of email snooping, where the democrats went after Reagan for making war without congressional authorization, Oliver North correctly and irreversibly deleted inconvenient emails from his local node, but the emails were backed up in the clear by the server.
There are other, simpler, ways of protecting at company servers. The server could just not backup emails (which I believe is the current Microsoft solution) This, however, exposes one to excessive data loss, and finer grained management at the server is pretty much an announcement "Here is where the bodies are buried".
Better to let the recipient do finer grained management.
James A. Donald:
I have not been keeping track of the problem of > > lawyers trolling through emails looking for lawsuits > > - what remedies are corporations using these days?
What is that market like? How are lawyers striking > > back? What do encryption based remedies provide > > that existing remedies fail to provide?
Ian G:
Well, the high value stuff is in areas like banking / > finance / securities where all comms must be kept.
That means all emails, all voice, all chat! So on the > one hand they are fighting to keep it all, and on the > other hand they are fighting to reduce the stuff kept.
So lots of money to be had if you can talk out both > sides of your mouth :-)
Tricky.
Talking out of both sides of ones mouth requires intimate knowledge of ones audience, and also a fair bit of plausible cover one's ass deniability.
If not for the problem of burying the bodies, the obvious solution would be to keep everything for ever with corporate escrow: the board and the ceo can access everything, but not everyone can access everything.
That solution, however, is a security hole. If the board can access everything, you supply a system that others can use access everything.
So we need a more decentralized solution:
Everything kept and secured by the particular node to which it is directed, and that node can delete it, lose it due to incompetence of bad luck, and control access to it.
Nodes located on servers may be escrowed and backed up, but all their interesting content is sent to the appropriate person - who is not located on a server.
Further, the escrow system is simply multiple logins for a particular entity - and it can happen that both logins get lost.
I could write this, but I am not the person who could sell it, nor the person who could market research it.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
jx9oIAkcxP2o6oVgHGOUTYnJQG3siQs1bEde2DRH
4Ub1E2RDW+ojMa/cxZtL6ma+oUQRUVH3tWiTIxyKS

Message # 45

Date: Fri, 26 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

Hagai Bar-El wrote:
Hi,
Okay, let's get to one point at a time...
Excellent!
At 23/05/06 23:36, Ian G wrote:
Small risk which means small expected cost, by orders
of magnitude.
Large benefit, because much cheaper deployment, by
orders of magnitude.
Orders of magnitude multipled by orders of magnitude :)
I think you got the expectancy screwed up in this calculation...
In 1/1E6 case, the case of MITM, the probability is low, but the stakes
(damage) is high.
I'm sorry, how did you decide the stakes / damage was high? Have you any logic or evidence to support that?
Also, how high? It has to be *exceptionally* high to make a difference - we are probably talking in millions here - given that we routinely accept MITMs of $1000 in phishing being not worth worrying about.
It was a person who got a false sense of security,
trusted your system, and got screwed.
Nah :) My system reveals that it doesn't cover the MITM for the first instance. If they trusted that to, er, be the reverse of what it said, then they *will* get screwed no matter what system we give them.
For the (1E6-1)/1E6 you are likely to get good protection, but good
protection against nothing, because there was nothing at stake, which
means you get close to zero. My initial point was that most e-mail
message do not need any security and are not put at any risk by not
being encrypted.
LOL.... yes, this is to some extent true. If there is no risk there is no protection needed.
Which is *precisely* what I'm arguing for MITMs.
So how do I argue the reverse for the great mass of email users?
Well, I'll leave that for another mail.
Of course not many messages will be MITM'ed, but not many messages are
worth it, or any protection, either...
Right, but look at the difference: We have some good numbers for eavesdropping. Not many, but thanks to recent news we can start to get a picture. Something like 10m people's phone calls in the US, and something similar in email (again, details are spotty). We have to stab in the dark here and make some wild estimates.
What's our numbers for MITM? I suppose we would have to look at phishing, now, and then reduce it for the "first opportunity MITM."
Either way - we should be able to agree that the risk / frequency of eavesdropping is many magnitudes over the risk / frequency of MITM.
a. There are truly very few circumstances where
a usable MITM-vulnerable system is worse than an
unusable MITM-resistant system. Kerchkoffs' 6th
principle is his most important, IMO - the system
must be usable under field conditions.
The law was written for a very specific scenario. It's a military
scenario where the average stake of a message is high.
No, I disagree. I've done military crypto, as a field grunt, and the stakes were low. The law is entirely applicable - in fact more applicable - for the grunt in the field. Try scribbling a cryptogram when it's raining, dark, your fingers are frozen, there's mud in your eyes, your pencil keeps slipping, and the red-covered torch under the honcho isn't worth squat ...
Oh, and some bastard is shooting at you. Kerckhoffs was writing for me, and all I was trying to say was that I had 2 WIA and no KIA... And I am sorely tempted to scream it over the radio in clear.
(It's a common assumption that military crypto is in some sense more serious - not really. It is just different. Especially, there is a concept of tactical codes and tactical info - ones that don't hold out too long because enemy will figure it out anyway. Almost all information in the military is tactical in some sense, not strategic.)
(No, I never *really* got shot at, but it is the realistic scenario of a field grunt.)
This is not
commercial e-mail where you have one message worth, say, $100K and a
million worth absolutely nothing. You can also assume that the $100K
message senders are a bit more aware than the rest, in average, so you
can expect just a bit more of them. They are the ones by whom the
success of the system will be determined, not the masses that just send
porn links to each other.
Yowsa! I hope we can keep these assumptions intact when we get to the MITM case. Coz, if the message truly is worth $100k, did you assume that they were allowed to run on a Windows platform? And how did you enforce that?
The MITM case you will suffer is indeed one of a million, but it's
probably the only one that counts. People that encrypt messages for no
reason cannot be counted into the success rate of the system.
Nope. People that encrypt messages that don't need encryption - that's a strawman. You don't know in advance what messages need protection.
You can't even ask the user, coz she doesn't know, and won't even know with any reliability _after_ she sent it.
The only tractable assumption is to encrypt everything the best you can. There is zero merit in assuming that in advance there are a few messages we just have to get right, unless you happen to have a big fat contract that specifies that.
(If you have one of those, do you feel like sharing it?? :)
b. Above, there is point 5. For those who make
a risk management decision that they are concerned
with the MITM risk, they can simply phone up their
other contact and do a key exchange over the phone,
like as in PGP. The system covers the initial MITM
threat - it just asks you to do the heavy lifting
of the phone in the case where you need that.
Right, and this is why I like your method. This option is probably the
most useful one, but unfortunately, it brings us back to the
inconveniences of today's systems...
Well, it doesn't bring us back to the inconveniences of today's systems, except in the 1% of cases where people decide to do it.
Then they decide. Excellent, their choice, we now have a system that segregates itself between people who care, and people who'll take what they can get for free.
I am just afraid of the 70% or so
of the 1/1E6 who will skip step 5 because of a false sense of security...
Nah, 99% at least. And, they won't do it because of a false sense of security. They'll do it because of risk management - it isn't worth it to them to do that step.
(They could be wrong of course. That's another story.)
c. You could make the case that there are people
that need MITM protection but don't know it. I
choose not to bother to protect those people,
because if they don't know, then they will do
something else which will compromise themselves,
such as install windows. (Not because I'm being
snarky or anything, just another risk management
decision.)
You see, but they (the MITM people) are your real customers, not the
masses.
?? I grant that if they were paying me, I'd do something different. But they ain't. So I won't.
(And if they paid me, what would I do, read out to them #5 in a loud clear voice? Whip them, beat them, lock them away if they weren't doing it?)
The masses don't need your e-mail encryption - they are fine
enough without it.
Yowsa! Where did this "need" thing come from?
The masses don't "need" the Internet, is that what you mean?
The to-be-MITM'ed guys, the ones who do send secrets
and who are subject to MITM may not know they have to fear MITM. They
are executives, lawyers, etc., and they do not even know what MITM is.
It *is* your business to bother with them because you are designing
their solution - they trust you and your security system (hopefully for
a pay :) )
Nope. It is their business to *pay* me for a system, and advice. Until they do that, they can go hang.
Certainly if I was in the business of selling crypto stuff to lawyers, I'd have that attitude.
I'm not.
d. You could make the case that people do know
but won't do the phone-up MITM. Again, I choose
not to make the phone call for them :)
You should not do the phone for them, but you should disclaim your
system properly. "Pick up the phone and verify this number, otherwise
you are subject to an attack that can be launched with $40 cost".
Sure.
e. Of course, if MITM was easy to solve, we would
solve it in the code. It's just not easy to solve.
Luckily it is so rare and so "high value" that we
can safely ignore it for the vast majority who fall
in the "low value" threats class.
My claim was that of the 1% messages that are worth encryption at all,
maybe 80% are worth a MITM.
Well, all of them are worth attacking. How we do the attack is simply economics. The big difference of the MITM v. eavesdropping is that the MITM is orders of magnitude times more expensive, in general.
MITM is difficult, but it's difficult when it's in real-time. E-mail
messages just lurk in your Internet-accessible mailbox for anything
between 5 minutes to five days until you pick them up. If you assume
that your opponent does not have the capability of breaking into your
POP mailbox then who exactly are you protecting yourself against?
Well, it is all about raising the bar. Are we
agreed that the system substantially raises the
bar?
Yes, it raises the bar. A generic pick-one-of-a-pile message sniffing
would become orders of magnitude harder, but I am not sure this is our
goal. It's great against wholesale surveillance, and this is a good
feature, but it's not all we're looking for.
Right. So what is our goal?
As you say, I should
be in the business of selling crypto. That's one goal. Funnily enough, it is entirely not my goal, but I recognise it as a goal.
It *is* the goal of PGP Inc. Funnily enough I feel somewhat underwhelmed by the prospect of following them into that business.
James might offers some choice words here :)
If my goal was here, it would be something like the largest amount of free crypto possible. That's just me. For e.g., my company wrote the Cryptix library, and we pushed it out under BSD licence. Although we watched Baltimore, RSA, and that German company rise to billions on stock exchange values doing much the same thing, we never thought of changing the price.
(Call me dumb ... many do ... but my market was in transactions, not crypto.)
(Call me stupidly dumb.)
Consider the MITM's attack. 1. he has to get
access to the wire. That means he is either an
insider, or he is mounting an active attack.
Which means the bar is already set a meter or
two above the ground.
That's the point of my previous post. He does not need access to the
wire, and he does not need to be an insider (although he could). The
attack does not even need to be on-line. He just needs access to your
mail files on the server, either by being an insider or by compromising
the server. If the key is not yet cached then he doesn't even need that
- he just needs to send the first mail with a forged "from" address.
Sure.
Of course, a casual lamer running Ethereal on his laptop in Starbucks
will be helpless against this scheme, but is this whom you're using
PGP (or alike) against?
(Hmmm... I'm not sure I follow ... do you mean
that the "casual lamer" is the attacker or the
defender?)
Sorry.
The "casual lamer" was intended as the attacker. He is probably the only
one who can sniff but who cannot MITM you. I believe that a real
opponent can do both.
Sure. A real opponent can beat this scheme. So when these dastardly types turn up, we'll improve it.
I agree that using your scheme will give something that is way above
the zero security that is granted today, but it is far off what
people expect when they actually turn to use encryption. For anyone
seeking "pretty good privacy" this will just provide a false sense of
security, I believe.
When they turn to use "high" security, they will
read about part 5, and phone up their contacts.
Agreed. Just make a proper disclaimer for the rest... :)
Oh, yeah. But, bear in mind, it is still secure!
Secure, being, completely and correctly covers those things I choose to include.
I choose not to include "first MITM opportunity."
I also choose not to include "trojan on Windows OS."
And, there is no protection included for "meteors, unicorns, sniper bullets."
And I'll argue certain threats are more likely than others :)
It's just like PGP. I use PGP all the time...
But I don't bother to do a key exchange except
once every 20 contacts, if that.
So do I.
Keep in mind, though, that you're still better off getting keys in
"manual" e-mails than over an automated protocol. I do not call to check
every key fingerprint either, but I would if this key would be cached
automatically.
Sure. You would incure some costs. Not my market.
But *I know when I need to do it*. I don't expect
PRZ to know when I need to do it. I don't expect
to blame PRZ because he didn't fix it for me.
Leave the guy alone, he was blamed enough in his life for his PGP :)
Ha!
Seriously, he's not expected to, and no system is expected to, and this
is why we don't have any system that does... They all leave it to you,
and it's probably the only way to do it securely.
Right. I say the same thing about MITM and the value of the message. Let's deliver a system that works, and sod the rest.
There are reasons for taking this attitude...
What's the risk? Someone gets MITM'd. It
would be like one in a million. What's the
benefit? The million.
But who is this one? This one would be the one who really needed
security, while the other million are the million messages that are
not even worth the wiretap and never needed security in the first place.
Who cares who is the one?
You should. Me also...
No, I don't. I can't predict him upfront.
Even if I could, I can't get him to do all the things I want. It's a statistical game, so I resort to statistics - someone's going to get it in the neck coz of me. Oh well, my compensation, my excuse as I enter the pearly gates, is that 1 million people
increased their safety.
(This holds true even if I was selling the product. Bugs exist.)
We're supposed to design security systems for people who need it. That's
at least what I do for a living...
Right, so we need to negotiate on goals.
We aren't responsible for the one. The one
didn't pay us. The one just wanted some
basic security, and didn't get it. The one
didn't read part 5.
Okay, I think that we will all agree that such a system is good, but
just as long as it does not create a false sense of security for that
one. People should all know that the system as it is in steps 1-4 is
only mildly safe, and anyone who really needs security should do #5.
This should probably solve our debate.
Yes.
The false sense of security is one of the biggest boguss-arsed arguments ever used :) It generally is imposed totally incorrectly.
It is easy to avoid a false sense of security.
You just state the security.
Easy. Done. End of story.
I think that it is crucial that this one knows the limits of the system,
because this one is the only one for whom the system is actually useful.
If he doesn't get it - we got nothing. That's my opinion... (You don't
care about the one who needs security and I don't care about the 1E6 who
don't...)
Right. We have *different* definitions of "secure" and different ideas about the market.
P.S. You would at least want to fix the situation in which the
opponent simply sends a single "Hi, what's up?" message with a fake
"from" address and his own key to his victim to get his own key
registered for any address. This is worse than a weak MITM - it's a
weak race condition... :)
Sure. Let's fix that after the first 100 users
are out there.... Let's play around with some
solutions.
Sure. Are you working on having this deployed?
Nope. I don't do email. (We wrote the PGP stuff in Java for Cryptix, too, but again, that was for my transactional work.)
The difference between SSH and SSLv2 is just that.
SSH was a fix for the password sniffing. SSLv2
was a fix for the MITM that didn't exist in SSLv1
(the cert-less variety). The difference was that
SSH exists wherever we want it, and SSL exists
only where we are so desperate we are out of
business if we don't have it.
I'm not sure about that. I find SSL very useful, not just for commerce,
also for corporate applications. It does not solve all security
problems, of course; nothing does. Yet, it does take a threat and
address it quite well. Same for SSH.
Funnily enough, in tech terms they are almost equivalent, having converged on the best of breed connection protocols. But their
philosophy is entirely different, and it shows in their choice of certs management.
iang

Message # 46

Date: Fri, 26 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Hagai Bar-El wrote:
He just needs access to your mail files on the server, > either by being an insider or by compromising the > server. If the key is not yet cached then he doesn't > even need that - he just needs to send the first mail > with a forged "from" address.
But if there is no existing relationship, there is nothing to steal. We do not actually want to secure true names. We want to secure true relationships, which are represented by names, names that seldom correspond precisely to true names.
There are two ways the establishment of a new relationship can be part of a scam:
One is the 419 scam, previously known as the Spanish Prisoner scam. "I am the niece of Charles Taylor, who desperately needs to sneak forty three million dollars out of Nigeria."
The other is the trusted name scam: "Amazing new offer from Rolex". Somewhat to my surprise, though huge numbers of people claimed to be offering "affordable Rolex" watches for sale, not one of them claimed to *be* Rolex, just as thousands of people have offered me a share of Charles Taylor's stolen millions, but not one of them has claimed to *be* Charles Taylor. They were always his niece, or ex girlfriend, or a corrupt bank officer, or some such.
So securing true names at the establishment of a relationship does not seem to be very useful in practice.
Similarly the payments processor scam involves a false claim of relationship, not a false name. Everyone in the scam uses his true email address, true website, and his true DBA. PKI is entirely irrelevant to the payment processor scam. To defeat the payment processor scam we need cryptographic linkage of a communication to an agreement between nyms, not to a nym, and the concept of a "true" nym is entirely irrelevant.
The "casual lamer" was intended as the attacker. He is > probably the only one who can sniff but who cannot > MITM you. I believe that a real opponent can do both.
But the KBG, the CIA, the FBI, and the IRS cannot MITM an existing relationship which is all that they are likely to want to MITM, if keys are routinely and automatically exchanged, indexed, and archived on setup of the relationship,
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
d6rWan4wOjc5G3DtZToBq6EAfBcRPFWPHEbctdet
4lrjMRRK1tX/kefFc8Y+YlQl7u90KrUBC/srutFYd

Message # 47

Date: Fri, 26 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
James A. Donald:
For example if one establishes a login that involves > > an email address, the web site setting up the > > account will usually send you an expected email.
Since the email is expected, cannot be forged, and > > establishes the keys.
Hagai Bar-El wrote:
It could be circumvented by malicious code on the > server, waiting for this e-mail with a new key to be > cached.
If there is malicious code on the server, or someone persistently watching and maliciously modifying what is on the wire, we are probably talking about the FBI or the CIA, not some random scammer. (And if there is malicious code on the client, which is rather more likely than the server, PKI is just as useless)
If the FBI owns the server, it is of high importance to keep that ownership secret. Active attacks are trivial to detect by out of band communications. So the FBI is only going to use active attacks on known high value targets in high value cases, who will be correspondingly inclined to test for active attacks. It is not going to actively attack the standardized messages sent out when setting up a bank account or joining an email mailing list - and conspiracies to overthrow the state are unlikely to involve standardized setup messages.
High value cases are usually an attack on a company, and the company generally owns its own server, keeps the server physically secure, and has people connect to it by VPN - and when we set up a VPN connection, we are back to securing true relationships, not true names.
Also, imagine a case in which a spam message forged to > be coming from known bank sites, attempts to lock into > known address-book slots, such as
"reports at citibank.com". If one day you actually enroll > with Citibank your messages may be compromised, at > least for a short while until this is found out.
The attack you suggest involves using apparent commonality of domain as evidence of relationship. This is a subcase of the problem of attacks based on false claims of relationship, which most commonly manifests as the payments processor scam. In the case you suggest, the attacker falsely using the domain name as evidence of relationship, which can be defeated by a DK system, which would also take care of a great many of today's scams. It is however not sufficiently general to take care of all the related scams, in particular the most common form of this scam, the payments processor scam.
In general, we need a mechanism where A provides proof to B of B's relationship to A, and B can present that to C, who also has a relationship to A - web of trust for relationships, rather than true names. I have not fully figured out such a system would work, but people have, however, figured out how DK would work.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Lz3AgtYj0DMy1H6/HVuE6hka9l+HvjFQVXf5z/B+
4IcdjbSI84CG47LaL8/inZfwELTIBo180ZFM4JdRD

Message # 48

Date: Fri, 26 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hi,
Okay, let's get to one point at a time...
At 23/05/06 23:36, Ian G wrote:
Small risk which means small expected cost, by orders
of magnitude.
Large benefit, because much cheaper deployment, by
orders of magnitude.
Orders of magnitude multipled by orders of magnitude :)
I think you got the expectancy screwed up in this calculation...
In 1/1E6 case, the case of MITM, the probability is low, but the stakes (damage) is high. It was a person who got a false sense of security, trusted your system, and got screwed.
For the (1E6-1)/1E6 you are likely to get good protection, but good protection against nothing, because there was nothing at stake, which means you get close to zero. My initial point was that most e-mail message do not need any security and are not put at any risk by not being encrypted.
Of course not many messages will be MITM'ed, but not many messages are worth it, or any protection, either...
a. There are truly very few circumstances where
a usable MITM-vulnerable system is worse than an
unusable MITM-resistant system. Kerchkoffs' 6th
principle is his most important, IMO - the system
must be usable under field conditions.
The law was written for a very specific scenario. It's a military scenario where the average stake of a message is high. This is not commercial e-mail where you have one message worth, say, $100K and a million worth absolutely nothing. You can also assume that the $100K message senders are a bit more aware than the rest, in average, so you can expect just a bit more of them. They are the ones by whom the success of the system will be determined, not the masses that just send porn links to each other.
The MITM case you will suffer is indeed one of a million, but it's probably the only one that counts. People that encrypt messages for no reason cannot be counted into the success rate of the system.
b. Above, there is point 5. For those who make
a risk management decision that they are concerned
with the MITM risk, they can simply phone up their
other contact and do a key exchange over the phone,
like as in PGP. The system covers the initial MITM
threat - it just asks you to do the heavy lifting
of the phone in the case where you need that.
Right, and this is why I like your method. This option is probably the most useful one, but unfortunately, it brings us back to the inconveniences of today's systems... I am just afraid of the 70% or so of the 1/1E6 who will skip step 5 because of a false sense of security...
c. You could make the case that there are people
that need MITM protection but don't know it. I
choose not to bother to protect those people,
because if they don't know, then they will do
something else which will compromise themselves,
such as install windows. (Not because I'm being
snarky or anything, just another risk management
decision.)
You see, but they (the MITM people) are your real customers, not the masses. The masses don't need your e-mail encryption - they are fine enough without it. The to-be-MITM'ed guys, the ones who do send secrets and who are subject to MITM may not know they have to fear MITM. They are executives, lawyers, etc., and they do not even know what MITM is. It *is* your business to bother with them because you are designing their solution - they trust you and your security system (hopefully for a pay :) )
d. You could make the case that people do know
but won't do the phone-up MITM. Again, I choose
not to make the phone call for them :)
You should not do the phone for them, but you should disclaim your system properly. "Pick up the phone and verify this number, otherwise you are subject to an attack that can be launched with $40 cost".
e. Of course, if MITM was easy to solve, we would
solve it in the code. It's just not easy to solve.
Luckily it is so rare and so "high value" that we
can safely ignore it for the vast majority who fall
in the "low value" threats class.
My claim was that of the 1% messages that are worth encryption at all, maybe 80% are worth a MITM.
MITM is difficult, but it's difficult when it's in real-time.
E-mail messages just lurk in your Internet-accessible mailbox for
anything between 5 minutes to five days until you pick them up. If
you assume that your opponent does not have the capability of
breaking into your POP mailbox then who exactly are you protecting
yourself against?
Well, it is all about raising the bar. Are we
agreed that the system substantially raises the
bar?
Yes, it raises the bar. A generic pick-one-of-a-pile message sniffing would become orders of magnitude harder, but I am not sure this is our goal. It's great against wholesale surveillance, and this is a good feature, but it's not all we're looking for.
Consider the MITM's attack. 1. he has to get
access to the wire. That means he is either an
insider, or he is mounting an active attack.
Which means the bar is already set a meter or
two above the ground.
That's the point of my previous post. He does not need access to the wire, and he does not need to be an insider (although he could). The attack does not even need to be on-line. He just needs access to your mail files on the server, either by being an insider or by compromising the server. If the key is not yet cached then he doesn't even need that - he just needs to send the first mail with a forged "from" address.
Of course, a casual lamer running Ethereal on his laptop in
Starbucks will be helpless against this scheme, but is this whom
you're using PGP (or alike) against?
(Hmmm... I'm not sure I follow ... do you mean
that the "casual lamer" is the attacker or the
defender?)
Sorry.
The "casual lamer" was intended as the attacker. He is probably the only one who can sniff but who cannot MITM you. I believe that a real opponent can do both.
I agree that using your scheme will give something that is way
above the zero security that is granted today, but it is far off
what people expect when they actually turn to use encryption. For
anyone seeking "pretty good privacy" this will just provide a false
sense of security, I believe.
When they turn to use "high" security, they will
read about part 5, and phone up their contacts.
Agreed. Just make a proper disclaimer for the rest... :)
It's just like PGP. I use PGP all the time...
But I don't bother to do a key exchange except
once every 20 contacts, if that.
So do I.
Keep in mind, though, that you're still better off getting keys in "manual" e-mails than over an automated protocol. I do not call to check every key fingerprint either, but I would if this key would be cached automatically.
But *I know when I need to do it*. I don't expect
PRZ to know when I need to do it. I don't expect
to blame PRZ because he didn't fix it for me.
Leave the guy alone, he was blamed enough in his life for his PGP :)
Seriously, he's not expected to, and no system is expected to, and this is why we don't have any system that does... They all leave it to you, and it's probably the only way to do it securely.
What's the risk? Someone gets MITM'd. It
would be like one in a million. What's the
benefit? The million.
But who is this one? This one would be the one who really needed
security, while the other million are the million messages that are
not even worth the wiretap and never needed security in the first place.
Who cares who is the one?
You should. Me also...
We're supposed to design security systems for people who need it.
That's at least what I do for a living...
We aren't responsible for the one. The one
didn't pay us. The one just wanted some
basic security, and didn't get it. The one
didn't read part 5.
Okay, I think that we will all agree that such a system is good, but just as long as it does not create a false sense of security for that one. People should all know that the system as it is in steps 1-4 is only mildly safe, and anyone who really needs security should do #5.
This should probably solve our debate.
I think that it is crucial that this one knows the limits of the system, because this one is the only one for whom the system is actually useful. If he doesn't get it - we got nothing. That's my opinion... (You don't care about the one who needs security and I don't care about the 1E6 who don't...)
P.S. You would at least want to fix the situation in which the
opponent simply sends a single "Hi, what's up?" message with a fake
"from" address and his own key to his victim to get his own key
registered for any address. This is worse than a weak MITM - it's a
weak race condition... :)
Sure. Let's fix that after the first 100 users
are out there.... Let's play around with some
solutions.
Sure. Are you working on having this deployed?
The difference between SSH and SSLv2 is just that.
SSH was a fix for the password sniffing. SSLv2
was a fix for the MITM that didn't exist in SSLv1
(the cert-less variety). The difference was that
SSH exists wherever we want it, and SSL exists
only where we are so desperate we are out of
business if we don't have it.
I'm not sure about that. I find SSL very useful, not just for commerce, also for corporate applications. It does not solve all security problems, of course; nothing does. Yet, it does take a threat and address it quite well. Same for SSH.
Regards,
Hagai.

Message # 49

Date: Fri, 26 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello,
At 24/05/06 00:42, James A. Donald wrote:
The proposed system takes care of most forms of MITM. It
is vulnerable to MITM on initial establishment of
communications, which is not a problem because nothing
much is at stake during initial establishment of
communications, and there is usually some out of band
reason for establishing communications that provides an
authenticity check during initial establishment of
communications.
I agree.
For example if one establishes a login that involves an
email address, the web site setting up the account will
usually send you an expected email. Since the email is
expected, cannot be forged, and establishes the keys.
It could be circumvented by malicious code on the server, waiting for this e-mail with a new key to be cached. The malicious code does not even have to run on the server - a bot scanning mailboxes on compromised servers every 10 minutes could be good enough.
Also, imagine a case in which a spam message forged to be coming from known bank sites, attempts to lock into known address-book slots, such as "reports at citibank.com". If one day you actually enroll with Citibank your messages may be compromised, at least for a short while until this is found out.
More interestingly, the FBI and KGB will be helpless
against this scheme.
I agree. Wholesale surveillance will be well mitigated.
Suppose I start conspiring with Ian to overthrow the
state and the NSA, CIA, FBI, KGB, IRS and Mossad want to
find out what we are saying. How are they going to use
MITM to penetrate our emails if we are using this
scheme?
When you do arrange that, count me in! :) They will not penetrate your e-mails, just like they cannot penetrate your e-mail if you use PGP. They will keep using their own *other* methods.
Hagai.

Message # 50

Date: Fri, 26 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

James A. Donald wrote:
Similarly the payments processor scam involves a false
claim of relationship, not a false name. Everyone in
the scam uses his true email address, true website, and
his true DBA. PKI is entirely irrelevant to the payment
processor scam. To defeat the payment processor scam we
need cryptographic linkage of a communication to an
agreement between nyms, not to a nym, and the concept of
a "true" nym is entirely irrelevant.
Hmm... What is "the payments processor scam" ?
iang

Message # 51

Date: Fri, 26 May 2006
From: Ian G
To: practicalsecurity at hbarel.com
Subject: [PracticalSecurity] Why we can propose weakness, dominate all,

There is some question about the relative benefits of different philosophies of protection. I personally sing to this rhythm:
do what you can for free,
then extend!
Call that 'A'. Others often set other targets. Many love to dance to this tune:
Cover all threats in the set 'B'
coz the paying customers deserve it!
So why would we choose one over the other?
The case for set B is based on custom. The set of threats included are those that have been selected by an arcane and tricky process but let's assume they are "good" for now.
The case for set A is based on economics. It walks like this.
Free is defined to be something that is of lesser or equal cost to the activity in question. Say we are sending an email. Free means there is no other activity or cost imposed on the sending of the email other than ... already necessary in sending the email.
(See earlier mail!)
Now, if we assume away (rotate arms like windmills here) the costs of implementation and deployment then that means that all people on the planet of email could have set A. For nothing.
Let's call that 99% of the emailing population.
Back to set B. Let's say (this is a *challengable* assumption but it suits today's logic) that Set B is "better" than Set A, and in fact is so much better we can call it "totally secure." Let's also assume there is 1% of the population that is "discerning" enough to demand set A and go through the cost of deploying it.
(Paying for it!) (Paying good money!) (Spending time!)
So we now have 99% using Set A, for free, and with "known weaknesses." Also, we have Set B which we claim have no weaknesses. But the 1% using 'B' had to pay to get there.
OK?
What happens?
Well, I'm sorry to say that normal *business* processes will kick in and totally destroy Set B. Completely and utterly. No matter how much better it is.
If 99% of the people in the corporation use Set A, then it will be the standard. It will be demanded to be the basis of everything. It will become the new lingua franca, the new way, the only way.
Verily, the definition of email.
Even if the corporation has a small group that needs securing, they will simply use Set A and bolster it.
It is far more economic to bolster Set A than to deploy Set B as well as Set A. They could even layer Set B over Set A... if they so decide.
Set A of course does not *preclude* the features in Set B. It just doesn't deliver them by default.
OTOH, Set B definately precludes the 99% usage base that is available to Set A. There is no way you can "reduce" Set B to cover the other 99%, because to do so means either you require them to pay (run away screaming!) or you need to break your assumptions about customary security (crawl in a hole and die!)
We know this to be true from experience. SSH covers 100% of its market area - telnet is now effectively only used for testing. Yet SSH has this tiny known weakness.
SSH actually went up against SSL-telnet. Not- withstanding that SSL-telnet had some sort of claim that it had "no weaknesses," it was trounced.
Not just trounced, it was destroyed, scattered to the winds, blown into the milky way.
The reason was costs.
The result was not pretty. Probably there are only a handful of people who even remember that SSL-telnet existed. And even fewer of those are prepared to admit that they used it, briefly.
OTOH, we still have a situation where SSL is only used in <1% of browsing. SSL claims complete security, but it never broke out of 1% usage.
Prediction: if someone invented HTTP tunnelling over SSH (of course, this is crazy talk), it would wipe out SSL within 2 years.
The reason: coz SSH costs $0. Economics rules over "security" whatever that latter word means.
And, "free" rules over "costs" no matter what the threats.
This business analysis is entirely stable (econ- speak for "better") no matter what you care to say about security. But even better, Set 'A' has the wonderful ability of improvement - as the threats arise, it can improve. It is this ability which makes it the honest, better choice; the ability to improve to keep pace with new threats.
It's a winner! But more importantly the price is right - as the threat is low, the price is low. As the threat rises, we can raise the price and meet more of the threat.
Try that with your Set 'B' !
iang
PS: We are about to see this experiment run in the VPN market.
PPS: We have the same situation with S/MIME, and PGP, although to properly contrast would be a rant for another day.
PPPS: There is only one way in which Set B can live in such a world. I'll leave that as an exercise for the reader.

Message # 52

Date: Fri, 26 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hi,
At 26/05/06 01:58, Ian G wrote:
I think you got the expectancy screwed up in this calculation...
In 1/1E6 case, the case of MITM, the probability is low, but the stakes
(damage) is high.
I'm sorry, how did you decide the stakes / damage
was high? Have you any logic or evidence to
support that?
My logic is that people who need security usually need it for a reason while people who just use it because it's automatic do not. A MITM is not done for nothing - if an opponent does a MITM then it's for something much more valuable than the typical random e-mail message that can be picked up (and which you do protect).
Also, how high? It has to be *exceptionally* high
to make a difference - we are probably talking in
millions here - given that we routinely accept
MITMs of $1000 in phishing being not worth worrying
about.
I do not know the actual average damage of a MITM, of course.
However, I do know the gain of protecting messages that do not require protection and it close to zero. Okay, if you're worried about wholesale surveillance then it's above zero, but it's close to zero otherwise.
It was a person who got a false sense of security,
trusted your system, and got screwed.
Nah :) My system reveals that it doesn't cover
the MITM for the first instance. If they
trusted that to, er, be the reverse of what
it said, then they *will* get screwed no matter
what system we give them.
I agree. All I was asking for is for the system to declare it's threat model. My claim was that it does not solve the usability problems of e-mail encryption (as PGP) for the cases where"real" security is needed and just lifts the bar for the rest.
For the (1E6-1)/1E6 you are likely to get good protection, but good
protection against nothing, because there was nothing at stake, which
means you get close to zero. My initial point was that most e-mail
message do not need any security and are not put at any risk by not
being encrypted.
LOL.... yes, this is to some extent true. If
there is no risk there is no protection needed.
Which is *precisely* what I'm arguing for MITMs.
So how do I argue the reverse for the great mass
of email users?
There is no risk for the masses, there *is* risk in the cases that are worth a MITM, because they are the 1/1E6 that are worth it. I will try to phrase it clearly: the great mass of e-mail messages do not care about MITM, but they do not care about your system either, because they have nothing at stake. The few messages that are at stake are also the messages that are worth being MITM'ed, and you don't help them much (well, you do, by step #5, but without improving the usability, which was the problem at hand).
Of course not many messages will be MITM'ed, but not many messages are
worth it, or any protection, either...
Right, but look at the difference: We have
some good numbers for eavesdropping. Not many,
but thanks to recent news we can start to get a
picture. Something like 10m people's phone calls
in the US, and something similar in email (again,
details are spotty). We have to stab in the dark
here and make some wild estimates.
I agree. This is wholesale surveillance. I may be old fashioned, but I still don't see this as part of my threat model.
What's our numbers for MITM? I suppose we would
have to look at phishing, now, and then reduce it
for the "first opportunity MITM."
Either way - we should be able to agree that
the risk / frequency of eavesdropping is many
magnitudes over the risk / frequency of MITM.
What is the risk? 10m people were wiretapped; so? What damage was caused?
I believe that there is no damage in MITM because most people who write e-mails that are worth a MITM, *do* use PGP or alike, or don't use e-mail.
a. There are truly very few circumstances where
a usable MITM-vulnerable system is worse than an
unusable MITM-resistant system. Kerchkoffs' 6th
principle is his most important, IMO - the system
must be usable under field conditions.
The law was written for a very specific scenario. It's a military
scenario where the average stake of a message is high.
No, I disagree. I've done military crypto, as a
field grunt, and the stakes were low. The law is
entirely applicable - in fact more applicable -
for the grunt in the field. Try scribbling a
cryptogram when it's raining, dark, your fingers
are frozen, there's mud in your eyes, your pencil
keeps slipping, and the red-covered torch under the
honcho isn't worth squat ...
Done that... ;)
I agree that a system must always be usable in field conditions, of course, but the term "usable" is lax and does not translate well from the military field into the commercial field. How usable? Does the need to negotiate keys make a system unusable? Is it like writing crypto in the rain, dark, with frozen fingers, etc.? I doubt...
I wrote what I wrote before about the average stakes to point out that "lifting the bar" for the masses is worth more with an unusable military system than with an unusable commercial system.
This is not
commercial e-mail where you have one message worth, say, $100K and a
million worth absolutely nothing. You can also assume that the $100K
message senders are a bit more aware than the rest, in average, so you
can expect just a bit more of them. They are the ones by whom the
success of the system will be determined, not the masses that just send
porn links to each other.
Yowsa! I hope we can keep these assumptions intact
when we get to the MITM case. Coz, if the message
truly is worth $100k, did you assume that they were
allowed to run on a Windows platform? And how did
you enforce that?
The $100K is not a final quote. :)
I wouldn't store a $100K value asset on Win32 either.
The point is that 1/1E6 messages are worth a lot (enough for a MITM - the number in dollars doesn't matter) and the rest are worth zero.
The MITM case you will suffer is indeed one of a million, but it's
probably the only one that counts. People that encrypt messages for no
reason cannot be counted into the success rate of the system.
Nope. People that encrypt messages that don't
need encryption - that's a strawman. You don't
know in advance what messages need protection.
You can't even ask the user, coz she doesn't
know, and won't even know with any reliability
_after_ she sent it.
The only tractable assumption is to encrypt
everything the best you can. There is zero
merit in assuming that in advance there are
a few messages we just have to get right,
unless you happen to have a big fat contract
that specifies that.
I am not sure I agree with the actual value of encrypting everything.
The only risk that you face with messages that were not considered as "sensitive" at the time of sending is with legal stuff, and this is outside your threat model anyway, because you must keep the keys and disclose them anyway when it gets to court.
Okay, I agree to attribute some benefit to all-inclusive encryption, but this is not the way, I believe, e-mail encryption success is to be determined. This probably takes us back to the first message of the thread.
(If you have one of those, do you feel like
sharing it?? :)
I would if I had. :)
b. Above, there is point 5. For those who make
a risk management decision that they are concerned
with the MITM risk, they can simply phone up their
other contact and do a key exchange over the phone,
like as in PGP. The system covers the initial MITM
threat - it just asks you to do the heavy lifting
of the phone in the case where you need that.
Right, and this is why I like your method. This option is probably the
most useful one, but unfortunately, it brings us back to the
inconveniences of today's systems...
Well, it doesn't bring us back to the inconveniences
of today's systems, except in the 1% of cases where
people decide to do it.
...And I claim that this is the only 1% that counts... I guess this is the root for the debate between us.
Then they decide. Excellent, their choice, we now
have a system that segregates itself between people
who care, and people who'll take what they can get
for free.
Agreed.
I am just afraid of the 70% or so
of the 1/1E6 who will skip step 5 because of a false sense of security...
Nah, 99% at least. And, they won't do it because
of a false sense of security. They'll do it because
of risk management - it isn't worth it to them to do
that step.
(They could be wrong of course. That's another story.)
I was more pessimistic - I did not say 70% but 70% of the 1/1E6...
c. You could make the case that there are people
that need MITM protection but don't know it. I
choose not to bother to protect those people,
because if they don't know, then they will do
something else which will compromise themselves,
such as install windows. (Not because I'm being
snarky or anything, just another risk management
decision.)
You see, but they (the MITM people) are your real customers, not the
masses.
?? I grant that if they were paying me, I'd
do something different. But they ain't. So
I won't.
You do it voluntarily, but you still do it for them... At least that's how I see it.
(BTW, after realizing that they are 1/1E6, even if they were paying it would probably not be worth it. :) )
The masses don't need your e-mail encryption - they are fine
enough without it.
Yowsa! Where did this "need" thing come from?
It's not "need" but "lack of need" and it came from the observation that nobody asked for e-mail encryption, nobody uses it (and don't give me this usability excuse - people do things less "usable" than PGP when they need to - like fighting with MS-Word indentation).
That's how it all started. Why don't people use encryption... Is it not usable or do they just don't think they need it... I claim the latter.
The masses don't "need" the Internet, is that
what you mean?
The masses do need the Internet, at least the porn sites... :)
The to-be-MITM'ed guys, the ones who do send secrets
and who are subject to MITM may not know they have to fear MITM. They
are executives, lawyers, etc., and they do not even know what MITM is.
It *is* your business to bother with them because you are designing
their solution - they trust you and your security system (hopefully for
a pay :) )
Nope. It is their business to *pay* me for a
system, and advice. Until they do that, they
can go hang.
This brings me to my original claim that the rest don't need e-mail encryption. They don't ask for it, and they don't use it. I agree that your system is useful, and will lift the bar; I just don't think that this is our main goal. The main goal are the people hanging above...
e. Of course, if MITM was easy to solve, we would
solve it in the code. It's just not easy to solve.
Luckily it is so rare and so "high value" that we
can safely ignore it for the vast majority who fall
in the "low value" threats class.
My claim was that of the 1% messages that are worth encryption at all,
maybe 80% are worth a MITM.
Well, all of them are worth attacking. How we
do the attack is simply economics. The big
difference of the MITM v. eavesdropping is that
the MITM is orders of magnitude times more
expensive, in general.
I agree. Eavesdropping costs close to zero when you're there and MITM costs more.
MITM is difficult, but it's difficult when it's in real-time. E-mail
messages just lurk in your Internet-accessible mailbox for anything
between 5 minutes to five days until you pick them up. If you assume
that your opponent does not have the capability of breaking into your
POP mailbox then who exactly are you protecting yourself against?
Well, it is all about raising the bar. Are we
agreed that the system substantially raises the
bar?
Yes, it raises the bar. A generic pick-one-of-a-pile message sniffing
would become orders of magnitude harder, but I am not sure this is our
goal. It's great against wholesale surveillance, and this is a good
feature, but it's not all we're looking for.
Right. So what is our goal?
Making security easier where strong security is needed. (not just lawyers etc., also you and I when needing strong security for privacy or business reasons).
If my goal was here, it would be something like the
largest amount of free crypto possible. That's just
me. For e.g., my company wrote the Cryptix library,
and we pushed it out under BSD licence. Although
we watched Baltimore, RSA, and that German company
rise to billions on stock exchange values doing much
the same thing, we never thought of changing the price.
(Call me dumb ... many do ... but my market was in
transactions, not crypto.)
(Call me stupidly dumb.)
I will not call you dumb. You decided to make a living off transactions - it was your choice and it's nice that you followed your charter and goals. There is no point in wondering forever on what could happen if your goals were different.
Of course, a casual lamer running Ethereal on his laptop in Starbucks
will be helpless against this scheme, but is this whom you're using
PGP (or alike) against?
(Hmmm... I'm not sure I follow ... do you mean
that the "casual lamer" is the attacker or the
defender?)
Sorry.
The "casual lamer" was intended as the attacker. He is probably the only
one who can sniff but who cannot MITM you. I believe that a real
opponent can do both.
Sure. A real opponent can beat this scheme. So
when these dastardly types turn up, we'll improve
it.
That's the thing - you can't. At least I don't know how. Your step #5 solves it, but it does not improve usability. I don't know how to.
Secure, being, completely and correctly covers those
things I choose to include.
I choose not to include "first MITM opportunity."
I also choose not to include "trojan on Windows OS."
And, there is no protection included for "meteors,
unicorns, sniper bullets."
And I'll argue certain threats are more likely than
others :)
I agree about the applicability of all claims but the MITM one of course. If you don't mitigate unicorns, it's okay, because people don't expect you to. However, if you don't protect against MITM in some modes, these modes are not worth much (only to the masses, which is what I don't count, and where we disagree).
But *I know when I need to do it*. I don't expect
PRZ to know when I need to do it. I don't expect
to blame PRZ because he didn't fix it for me.
Leave the guy alone, he was blamed enough in his life for his PGP :)
Ha!
Seriously, he's not expected to, and no system is expected to, and this
is why we don't have any system that does... They all leave it to you,
and it's probably the only way to do it securely.
Right. I say the same thing about MITM and the
value of the message. Let's deliver a system that
works, and sod the rest.
There are reasons for taking this attitude...
I can agree with this.
This is why I said that regardless of my "concerns" I still think your system should be deployed.
We're supposed to design security systems for people who need it. That's
at least what I do for a living...
Right, so we need to negotiate on goals.
Indeed...
We aren't responsible for the one. The one
didn't pay us. The one just wanted some
basic security, and didn't get it. The one
didn't read part 5.
Okay, I think that we will all agree that such a system is good, but
just as long as it does not create a false sense of security for that
one. People should all know that the system as it is in steps 1-4 is
only mildly safe, and anyone who really needs security should do #5.
This should probably solve our debate.
Yes.
The false sense of security is one of the
biggest boguss-arsed arguments ever used :)
It generally is imposed totally incorrectly.
It is easy to avoid a false sense of security.
You just state the security.
Easy. Done. End of story.
I actually agree with this.
False sense of security is not always such a big issue to resolve.
I think that it is crucial that this one knows the limits of the system,
because this one is the only one for whom the system is actually useful.
If he doesn't get it - we got nothing. That's my opinion... (You don't
care about the one who needs security and I don't care about the 1E6 who
don't...)
Right. We have *different* definitions of
"secure" and different ideas about the market.
Yap.
Actually, I think we have different views only of the market. The "secure" is implied from it.
Best,
Hagai.

Message # 53

Date: Fri, 26 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello,
At 26/05/06 04:54, James A. Donald wrote:
Hagai Bar-El wrote:
He just needs access to your mail files on the server,
either by being an insider or by compromising the
server. If the key is not yet cached then he doesn't
even need that - he just needs to send the first mail
with a forged "from" address.
But if there is no existing relationship, there is
nothing to steal. We do not actually want to secure true
names. We want to secure true relationships, which are
represented by names, names that seldom correspond
precisely to true names.
Right, but if the establishment phase of a relationship is also your root of trust then it is not that meaningless anymore. This first message you get form Amazon may mean nothing to you today - you know exactly that they want to say. However, when this bootstrapping message will also include a key that will be cached then this message gets its importance, and it's sensitivity, right there.
There are two ways the establishment of a new
relationship can be part of a scam:
One is the 419 scam, previously known as the Spanish
Prisoner scam. "I am the niece of Charles Taylor, who
desperately needs to sneak forty three million dollars
out of Nigeria."
The other is the trusted name scam: "Amazing new offer
from Rolex". Somewhat to my surprise, though huge
numbers of people claimed to be offering "affordable
Rolex" watches for sale, not one of them claimed to *be*
(snip)
Right. True names are valueless. It's the nyms that count for whatever they represent.
Similarly the payments processor scam involves a false
claim of relationship, not a false name. Everyone in
the scam uses his true email address, true website, and
his true DBA. PKI is entirely irrelevant to the payment
processor scam. To defeat the payment processor scam we
need cryptographic linkage of a communication to an
agreement between nyms, not to a nym, and the concept of
a "true" nym is entirely irrelevant.
Right. It's not the nym by what it represents - the relationship or the potential relationship based on other link-able data (such as when evaluating endorsements).
The "casual lamer" was intended as the attacker. He is
probably the only one who can sniff but who cannot
MITM you. I believe that a real opponent can do both.
But the KBG, the CIA, the FBI, and the IRS cannot MITM
an existing relationship which is all that they are
likely to want to MITM, if keys are routinely and
automatically exchanged, indexed, and archived on setup
of the relationship,
They cannot MITM an existing relationship, but they can MITM when such starts. After all, they can tell what relationships are interesting for them and what are not before they are formed (at least in some of the cases).
If I wanted to avoid the FBI etc., I would have exchanged the keys manually (as in PGP) or use step #5.
Hagai.

Message # 54

Date: Fri, 26 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello,
At 26/05/06 06:05, James A. Donald wrote:
Hagai Bar-El wrote:
It could be circumvented by malicious code on the
server, waiting for this e-mail with a new key to be
cached.
If there is malicious code on the server, or someone
persistently watching and maliciously modifying what is
on the wire, we are probably talking about the FBI or
the CIA, not some random scammer. (And if there is
malicious code on the client, which is rather more
likely than the server, PKI is just as useless)
I agree we're not protecting against the "random scammer". He is the Starbucks lamer from my thread with Ian. However, our opponent is not the FBI either. He can be anyone the business people who use e-mail encryption are afraid of. A hacker hired by a rival business, or alike (all the financially motivated break-ins).
When end-to-end security is used it is precisely also to mitigate server-based threats and to accommodate the general distrust in servers, that you do not always maintain. Otherwise you would base all the e-mail security stuff on the server and resolve the usability problems even further.
If the FBI owns the server, it is of high importance to
keep that ownership secret. Active attacks are trivial
to detect by out of band communications. So the FBI is
only going to use active attacks on known high value
targets in high value cases, who will be correspondingly
inclined to test for active attacks. It is not going to
actively attack the standardized messages sent out when
setting up a bank account or joining an email mailing
list - and conspiracies to overthrow the state are
(snip)
The FBI is not my main threat.
However, to your point, if the FBI really owns the server they can do all the MITM they want without you having a chance to discover it. If the opponent is on your server it will be very hard for you to detect a MITM (unless going off-band).
High value cases are usually an attack on a company, and
the company generally owns its own server, keeps the
server physically secure, and has people connect to it
by VPN - and when we set up a VPN connection, we are
back to securing true relationships, not true names.
Again, assuming server robustness is a threat-model issue.
Consider, however, that if one takes over a server for this purpose is does not need to be the highly protected server but can be the DMZ one, or any other server that gets the mail before it enters the company's server.
Also, imagine a case in which a spam message forged to
be coming from known bank sites, attempts to lock into
known address-book slots, such as
"reports at citibank.com". If one day you actually enroll
with Citibank your messages may be compromised, at
least for a short while until this is found out.
The attack you suggest involves using apparent
commonality of domain as evidence of relationship. This
is a subcase of the problem of attacks based on false
claims of relationship, which most commonly manifests as
the payments processor scam. In the case you suggest,
the attacker falsely using the domain name as evidence
of relationship, which can be defeated by a DK system,
which would also take care of a great many of today's
scams. It is however not sufficiently general to take
(snip)
I agree.
The point I was making was primarily to demonstrate that the automatic key registration method can be attacked by the existent problem of fake domain names and "from" addresses. Unfortunately, this problem of fake domain names is probably here to stay, at least for a while. Therefore, we must be sure that secure system we design for improving the current status do not rely on the trustworthiness of "from" fields.
Hagai.

Message # 55

Date: Fri, 26 May 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all, and be back in time for tea
Cc: practicalsecurity at hbarel.com

Hi,
At 26/05/06 11:48, Ian G wrote:
There is some question about the relative benefits of
different philosophies of protection. I personally
sing to this rhythm:
do what you can for free,
then extend!
Call that 'A'. Others often set other targets. Many
love to dance to this tune:
Cover all threats in the set 'B'
coz the paying customers deserve it!
So why would we choose one over the other?
I trust I am your endorser for "Set B"...
I don't think we should choose one over the other. Having two modes (with step #5 [Set B] and without step #5 [Set A]) is just great by me, and that's what I keep saying from the start.
The case for set B is based on custom. The set of
threats included are those that have been selected
by an arcane and tricky process but let's assume
they are "good" for now.
The "tricky process" is called a threat-analysis.
I think I was convincing enough about the ease of off-line MITM.
The case for set A is based on economics. It walks
like this.
Free is defined to be something that is of lesser
or equal cost to the activity in question. Say we
are sending an email. Free means there is no other
activity or cost imposed on the sending of the email
other than ... already necessary in sending the email.
(See earlier mail!)
Now, if we assume away (rotate arms like windmills here)
the costs of implementation and deployment then that
means that all people on the planet of email could
(snip)
Agreed.
The 99% get it for free. They don't necessarily need it, but they get it, and since it's free, no one has any reason to object.
Back to set B. Let's say (this is a *challengable*
assumption but it suits today's logic) that Set B is
"better" than Set A, and in fact is so much better
we can call it "totally secure." Let's also assume
there is 1% of the population that is "discerning"
enough to demand set A and go through the cost of
deploying it.
(Paying for it!) (Paying good money!) (Spending time!)
So we now have 99% using Set A, for free, and with
"known weaknesses." Also, we have Set B which we
(snip)
Yes!
What happens?
Well, I'm sorry to say that normal *business* processes
will kick in and totally destroy Set B. Completely
and utterly. No matter how much better it is.
Really? Like TABs destroyed SecureID? (LOL) Like FedEx destroyed Brink's?
Like downloadable browser applets with PINs destroyed smartcards?
Many people need little security (or none). Some people need strong security. Some products give low security (Set A) and some products, or enhancements to the same products, give more security (Set B).
These Set B's can be and are sometimes orders of magnitude more expensive and they still live; live well.
If 99% of the people in the corporation use Set A,
then it will be the standard. It will be demanded
to be the basis of everything. It will become the
new lingua franca, the new way, the only way.
Verily, the definition of email.
Even if the corporation has a small group that needs
securing, they will simply use Set A and bolster it.
It is far more economic to bolster Set A than to
deploy Set B as well as Set A. They could even
layer Set B over Set A... if they so decide.
Right. In our case, Set B (steps 1-5) is a superset of Set A (steps 1-4) that costs more (manual key management) and gives more. What's wrong?
Set A of course does not *preclude* the features
in Set B. It just doesn't deliver them by default.
OTOH, Set B definately precludes the 99% usage
base that is available to Set A. There is no way
you can "reduce" Set B to cover the other 99%,
because to do so means either you require them
to pay (run away screaming!) or you need to break
your assumptions about customary security (crawl
in a hole and die!)
This is a system-design issue. Nobody said that a single product cannot do both Set A and Set B and fall-back if this is desired. I don't get your point. Even your own suggestion was a single system that supports both (with or without step #5). I was only claiming that the "with step #5" is no more usable than e-mail security today, and without step #5 is not secure enough for most cases where security is needed.
We know this to be true from experience. SSH
covers 100% of its market area - telnet is now
effectively only used for testing. Yet SSH has
this tiny known weakness.
Right, and I have no problem with that. I use SSH myself. I have no problem because:
1. The MITM needs to be on-line, which is tough. In your case it can be off-line.
2. I engage in the "risky" process once in five years, not once in a month (when introducing a new correspondent).
SSH actually went up against SSL-telnet. Not-
withstanding that SSL-telnet had some sort of
claim that it had "no weaknesses," it was trounced.
Not just trounced, it was destroyed, scattered to
the winds, blown into the milky way.
The reason was costs.
Cost-benefit, to be exact.
SSL-Telnet gave too little added benefit for its added cost. I agree.
I would never use it.
The result was not pretty. Probably there are
only a handful of people who even remember that
SSL-telnet existed. And even fewer of those are
prepared to admit that they used it, briefly.
To be honest, I did not even know it ever existed...
OTOH, we still have a situation where SSL is only
used in <1% of browsing. SSL claims complete
security, but it never broke out of 1% usage.
Maybe that's because only 1% of the browsing requires security...
Don't forget that SSL does have it's cost in terms of performance. If people don't need security they will not switch it on just because it's there. It has nothing to do with the design of SSL as requiring certificates.
Fact is, even on the servers that support SSL and have the certificates and all (added cost over SSH was already paid), most pages are not encrypted even though it's a checkbox away with no extra cost.
Prediction: if someone invented HTTP tunnelling
over SSH (of course, this is crazy talk), it
would wipe out SSL within 2 years.
Yeah, unless common browsers start caching self signed certificates.
However, even though SSH will kill SSL for its low setup costs, no more than 1% of the pages will be encrypted, for the reasons I wrote above.
The reason: coz SSH costs $0. Economics rules
over "security" whatever that latter word means.
"security", whatever the word means, is part of "economics" - they are not ones against the other. This is what risk management is all about.
And, "free" rules over "costs" no matter what the
threats.
I strongly disagree.
It's not true anywhere and it's not true in security, otherwise people would still use passwords for the VPN's and not bother with HW tokens, and there are dozens of other examples.
This business analysis is entirely stable (econ-
speak for "better") no matter what you care to
say about security. But even better, Set 'A'
has the wonderful ability of improvement - as
the threats arise, it can improve. It is this
ability which makes it the honest, better choice;
the ability to improve to keep pace with new threats.
The evolution of Set A is to Set B (with step #5) and I agree that this makes the scheme appealing for giving everyone what he may want.
It's a winner! But more importantly the price
is right - as the threat is low, the price is
low. As the threat rises, we can raise the
price and meet more of the threat.
Right.
Try that with your Set 'B' !
B is part of the above deal. Otherwise you would not have the "...we can raise the price and meet more of the threat".
The only alternative we mentioned (PGP-like things) is one that does only a Set B functionality and does not fall back. The added value of the SetA+SetB system you're proposing is the value to Set-A users - people who want nothing and get a little.
It's a good system. I like it. I just note that for "e-mail encryption users", that are, the Set B users, we don't add anything.
Hagai.

Message # 56

Date: Sat, 27 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

--
Ian G wrote:
PS: We are about to see this experiment run in the VPN > market.
Not sure what you are referring to. What system do see providing or going to provide routine VPN encryption?
IKEv2?
PPS: We have the same situation with S/MIME, and PGP, > although to properly contrast would be a rant for > another day.
S/MIME and PGP are both expensive, especially S/MIME, and so neither one is much used. What is the "situation" to which you refer.
PPPS: There is only one way in which Set B can live in > such a world. I'll leave that as an exercise for the > reader.
This reader fails that exercise.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
NMO7ZXOJbKwZyBtVw7kebGu33R8sCZ/OEhAfWpFp
4TXwhYeGAlZ+UZnMUO54AtY/yPVTszYMmwThdQgUB

Message # 57

Date: Sat, 27 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

--
Hagai Bar-El wrote:
Maybe that's because only 1% of the browsing requires > security... Don't forget that SSL does have it's cost > in terms of performance. If people don't need security > they will not switch it on just because it's there. It > has nothing to do with the design of SSL as requiring > certificates.
It has everything to do with its cost as requiring certificates. It takes a skilled engineer half a day to drop in a new certificate. Sites that do serious money, such as the Gold Casino run for weeks with an expired certificate, because introducing a new certificate is frighteningly hard.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Blg2QdTIIm9R3A+MsaJQl8JiO10BQdyY+mAPLu94
4KwlloXy4hvSLFXXRH9fMhZhz9gRVwx3daR4VQ6TD

Message # 58

Date: Sat, 27 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
James A. Donald:
But if there is no existing relationship, there is > > nothing to steal. We do not actually want to secure > > true names. We want to secure true relationships, > > which are represented by names, names that seldom > > correspond precisely to true names.
Hagai Bar-El
Right, but if the establishment phase of a
relationship is also your
root of trust then it is not that meaningless anymore.
He has to keep the active attack going over a long period while your relationship becomes valuable. If he does this to any significant number of targets, his scam will be detected before it yields anything of value.
Persistent active attacks are extremely vulnerable to detection. Plus, it is simply hard to do. A persistent active attack has to be done perfectly every time, over a long time. By and large, the CIA is composed of blundering idiots.
It raises the bar beyond that achievable by the typical Nigerian scammer, to levels that present a major obstacle to the KGB and CIA.
But the KBG, the CIA, the FBI, and the IRS cannot > > MITM an existing relationship which is all that they > > are likely to want to MITM, if keys are routinely > > and automatically exchanged, indexed, and archived > > on setup of the relationship,
Hagai Bar-El
They cannot MITM an existing relationship, but they > can MITM when such starts.
But when it starts they will not know, the participants generally will not know, that it is conspiracy to do things that the CIA is interested in. If they persistently MITM everyone, or even any substantial number of people, or even one person in the entire world for any lengthy period, they are going to be detected.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
1/rBIXJL47bVKeIgcd7SHvjU+mtP7YL5IB+riMR3
4YLO7PvZ7lsb9qHOnHBAHMO6HY+qgzNz1TdQ/pYt7

Message # 59

Date: Sat, 27 May 2006
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Hagai Bar-El wrote:
I agree we're not protecting against the "random > scammer". He is the Starbucks lamer from my thread > with Ian. However, our opponent is not the FBI either.
He can be anyone the business people who use e-mail > encryption are afraid of. A hacker hired by a rival > business, or alike (all the financially motivated > break-ins).
SSL tends to be used to construct forts with an impregnable wall in front, no wall at all on the back, a gate through the front wall secured by a piece of chewing gum, and a security door on the side that has been propped ajar by a chair.
Your scenario is a typical SSL scenario - let us suppose an invincibly powerful attacker who uses his immense power to do the thing that is most difficult, and least profitable, to do, while ignoring all the threats that are much easier and more profitable for the attacker.
A business mail server is typically located inside the perimeter. If a hacker breaks in there, he is going to have richer and easier targets than MITMing email.
If a hacker has control of the company server, the company has considerably bigger problems than MITM.
Further, to if we are caching keys on establishment of a relationship, the hacker has to have permanent, durable, and reliable control of the company server. That is a mighty high bar for the hacker.
Further, MITM is trivial to detect. Permanent control of the company server is such a valuable asset he should not risk it by MITMing everything, or indeed anything.
The FBI is not my main threat. However, to your point, > if the FBI really owns the server they can do all the > MITM they want without you having a chance to discover > it.
Sure I can detect it. It is trivial to detect. I might get a business card or printout with the guys real key fingerprint on it, or if I am doing something that FBI or IRS is seriously hot about, I might be so paranoid as to check his public key fingerprint over my phone. Or they might screw up from time to time, and fail to modify some mail, or balls up by modifying mail that they should not be modifying.
So the FBI and CIA is only going to MITM a very small number of high value targets, and when those targets initiated their relationship, the FBI probably did not know they were high value
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
T6CXLpX+bPh5LZ2Vhanmfnxgrmjv3b16cgtjldvM
4nD9++PLKVWQ7gP1fcdvaIbGJLgzsdKo3nKbolFJH

Message # 60

Date: Sat, 27 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

James A. Donald wrote:
--
Ian G wrote:
PS: We are about to see this experiment run in the VPN
market.
Not sure what you are referring to. What system do see
providing or going to provide routine VPN encryption?
IKEv2?
SSH :) They now have a VPN tunnel mode which has been released in the latest distro, but it is not in the OS distros as yet, so I haven't tried it yet.
My hopeful comments:
https://www.financialcryptography.com/mt/archives/000617.html
PPS: We have the same situation with S/MIME, and PGP,
although to properly contrast would be a rant for
another day.
S/MIME and PGP are both expensive, especially S/MIME,
and so neither one is much used. What is the
"situation" to which you refer.
Right, that - in that both of them cost in different ways, and the end result is that they are both 1%-ers. If we could combine the strengths, we'd have 99%.
PPPS: There is only one way in which Set B can live in
such a world. I'll leave that as an exercise for the
reader.
This reader fails that exercise.
Maybe I was too cute :) This was one of those thoughts that I decided to leave out as being too much, too many words, too new.
Let's assume that the rant itself is plausible and the conclusion - that Set A wipes out Set B in a fair fight - is solid.
In which case, the only thing left is an unfair fight. Set B, or the proponents thereof, have to basically destroy Set A in *other* ways. E.g., ban it or otherwise downgrade it so severely that it is treated as "worse than any alternate."
Set A basically has to be perceived as "worse than nothing" which in itself is an extraordinary statement. It has to be demonised. It has to be hounded out of existence by foul means, as fair means aren't helpful to the cause.
And then we come to the MITM.
(Note, I'm excluding Hagai's alternate view where Set 'B' is an *extension* of Set 'A' here.)
(Also note that the above is an early set of thoughts. It only popped out at the end of the prior rant - I wouldn't claim it a reliable theory yet.)
iang

Message # 61

Date: Sat, 27 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

Hagai Bar-El wrote:
Hi,
At 26/05/06 01:58, Ian G wrote:
I think you got the expectancy screwed up in this calculation...
In 1/1E6 case, the case of MITM, the probability is low, but the stakes
(damage) is high.
I'm sorry, how did you decide the stakes / damage
was high? Have you any logic or evidence to
support that?
My logic is that people who need security usually need it for a reason
while people who just use it because it's automatic do not. A MITM is
not done for nothing - if an opponent does a MITM then it's for
something much more valuable than the typical random e-mail message that
can be picked up (and which you do protect).
I have to think about that for a bit, but here's my intuition - it sounds dangerously circular. It sounds like you would be saying that you are looking for a market that truly appreciates the need for MITM protection, and then you will be comfortable specifying MITM to protect them, because they are by definition needy for it.
Also, how high? It has to be *exceptionally* high
to make a difference - we are probably talking in
millions here - given that we routinely accept
MITMs of $1000 in phishing being not worth worrying
about.
I do not know the actual average damage of a MITM, of course.
However, I do know the gain of protecting messages that do not require
protection and it close to zero. Okay, if you're worried about wholesale
surveillance then it's above zero, but it's close to zero otherwise.
Well, it is close to zero - in the aggregate.
But it is not zero over all. We could hazard some guesses here, and I'd say that we might find ourselves being comfortable with say $100 for an average rich country consumer's email over a year (consider marketing costs, etc, and how much a data broker might make selling access to this).
Today's post, in honour of the question:
https://www.financialcryptography.com/mt/archives/000733.html
Try this pop quiz. If all your email was worth $100 to you, would that make it worth protecting at the "all" level, even if that left out some protections such as MITM?
Or, at what point would you say, "ok, let's do all of it?" $10? $1000?
It was a person who got a false sense of security,
trusted your system, and got screwed.
Nah :) My system reveals that it doesn't cover
the MITM for the first instance. If they
trusted that to, er, be the reverse of what
it said, then they *will* get screwed no matter
what system we give them.
I agree. All I was asking for is for the system to declare it's threat
model.
I think this is something that we should be stressing - even going so far as to suggest it be done in human readable terms.
My claim was that it does not solve the usability problems of
e-mail encryption (as PGP) for the cases where"real" security is needed
and just lifts the bar for the rest.
Right. It does all that. There are some important side benefits though. One I just posted about :)
Another is that it is possible to solve the "real" security for the 99% once they have a system in place - they just upgrade. So if you like, it can be treated as a two-phase operation: First, give them the free thing. Second, upgrade them to the real thing.
Those who have seen marketing at close hand will see this easily.
For the (1E6-1)/1E6 you are likely to get good protection, but good
protection against nothing, because there was nothing at stake, which
means you get close to zero. My initial point was that most e-mail
message do not need any security and are not put at any risk by not
being encrypted.
LOL.... yes, this is to some extent true. If
there is no risk there is no protection needed.
Which is *precisely* what I'm arguing for MITMs.
So how do I argue the reverse for the great mass
of email users?
There is no risk for the masses, there *is* risk in the cases that are
worth a MITM, because they are the 1/1E6 that are worth it. I will try
to phrase it clearly: the great mass of e-mail messages do not care
about MITM, but they do not care about your system either, because they
have nothing at stake. The few messages that are at stake are also the
messages that are worth being MITM'ed, and you don't help them much
(well, you do, by step #5, but without improving the usability, which
(snip)
See above. Bear in mind that you are assuming that there is zero threat to the masses - I would point out that this is a convenient assumption, and isn't really true.
We can claim it is true, but in general, that's only because we are trying to create a model that works.
For example, those selling difficult-to-install product will often claim it is true, so they create the discrimination (marketing term) that justifies the sale of the product.
But that's just words. It simply isn't a good assumption, just one malleable enough for various purposes.
Of course not many messages will be MITM'ed, but not many messages are
worth it, or any protection, either...
Right, but look at the difference: We have
some good numbers for eavesdropping. Not many,
but thanks to recent news we can start to get a
picture. Something like 10m people's phone calls
in the US, and something similar in email (again,
details are spotty). We have to stab in the dark
here and make some wild estimates.
I agree. This is wholesale surveillance. I may be old fashioned, but I
still don't see this as part of my threat model.
Ah. Then you might live in a country where they have strong traditions about data protection. The places where they are getting excited about current threats are the places where data is a tradeable asset, not something to be protected.
The thing about Echelon was that it was mostly benign and useless while the heavily fortified security agencies were the only ones with access (I include benefit to them when I say benign and useless :) .
But we are seeing the breaking down of the fortress walls of the agencies.
Now, we have the prospect of all that surveillance being available to any agency that might be in the current war of the month. When you add that into the rates of corruption and so forth, you now have a threat to the ordinary person.
What's our numbers for MITM? I suppose we would
have to look at phishing, now, and then reduce it
for the "first opportunity MITM."
Either way - we should be able to agree that
the risk / frequency of eavesdropping is many
magnitudes over the risk / frequency of MITM.
What is the risk? 10m people were wiretapped; so? What damage was caused?
None - as long as the data is protected within the fortified silos of intel agencies. Now we have to consider that the information is no longer protected, and it is quite reasonable to use it in wide circumstances.
I believe that there is no damage in MITM because most people who write
e-mails that are worth a MITM, *do* use PGP or alike, or don't use e-mail.
Well, again, that's now drifting into self-selection and circular logic.
I don't think most people who use PGP are at risk of MITM. I think they all tell themselves they are.
But that's culture, not reality of their threat models.
In this sense the early PGP community made the same mistake as the PKI people - they adopted the hard core national security model as gospel. These days nobody bothers with that, they just use PGP, they don't do much in the way of key exchanges, and they get on fine.
(Many however know that they should do a PGP key exchange when needed.)
a. There are truly very few circumstances where
a usable MITM-vulnerable system is worse than an
unusable MITM-resistant system. Kerchkoffs' 6th
principle is his most important, IMO - the system
must be usable under field conditions.
The law was written for a very specific scenario. It's a military
scenario where the average stake of a message is high.
No, I disagree. I've done military crypto, as a
field grunt, and the stakes were low. The law is
entirely applicable - in fact more applicable -
for the grunt in the field. Try scribbling a
cryptogram when it's raining, dark, your fingers
are frozen, there's mud in your eyes, your pencil
keeps slipping, and the red-covered torch under the
honcho isn't worth squat ...
Done that... ;)
:) Luckily I'm now old enough not to be challenged on it.
I agree that a system must always be usable in field conditions, of
course, but the term "usable" is lax and does not translate well from
the military field into the commercial field. How usable? Does the need
to negotiate keys make a system unusable? Is it like writing crypto in
the rain, dark, with frozen fingers, etc.? I doubt...
I wrote what I wrote before about the average stakes to point out that
"lifting the bar" for the masses is worth more with an unusable military
system than with an unusable commercial system.
My point was simply that usability dominates all.
If the system is unusable, it won't be used, and messages will bypass the system. So the higher goal won't be achieved; I think this is true across all domains, but the details differ of course.
This is not
commercial e-mail where you have one message worth, say, $100K and a
million worth absolutely nothing. You can also assume that the $100K
message senders are a bit more aware than the rest, in average, so you
can expect just a bit more of them. They are the ones by whom the
success of the system will be determined, not the masses that just send
porn links to each other.
Yowsa! I hope we can keep these assumptions intact
when we get to the MITM case. Coz, if the message
truly is worth $100k, did you assume that they were
allowed to run on a Windows platform? And how did
you enforce that?
The $100K is not a final quote. :)
Of course :) Although I will point out that the phishing number of $1000 is quite robust these days.
It isn't a message that got MITM'd but it is a loss that incurred because of an MITM.
I have heard of one case where an MITM was worth about $1,000,000. A politician in california MITM'd an opponents email at the DNS level, and used the emails to embarress the opponent out of the race.
But in practice the message MITM remains deliciously out of statistical reach.
I wouldn't store a $100K value asset on Win32 either.
The point is that 1/1E6 messages are worth a lot (enough for a MITM -
the number in dollars doesn't matter) and the rest are worth zero.
I doubt that's sustainable! We simply don't know which messages are worth a lot, a priori. Neither does the sender.
(See case above. If you asked that opponent whether her sex-chat was worth $1,000,000 before hand she wouldn't have known what you were talking about.)
The MITM case you will suffer is indeed one of a million, but it's
probably the only one that counts. People that encrypt messages for no
reason cannot be counted into the success rate of the system.
Nope. People that encrypt messages that don't
need encryption - that's a strawman. You don't
know in advance what messages need protection.
You can't even ask the user, coz she doesn't
know, and won't even know with any reliability
_after_ she sent it.
The only tractable assumption is to encrypt
everything the best you can. There is zero
merit in assuming that in advance there are
a few messages we just have to get right,
unless you happen to have a big fat contract
that specifies that.
I am not sure I agree with the actual value of encrypting everything.
The only risk that you face with messages that were not considered as
"sensitive" at the time of sending is with legal stuff, and this is
outside your threat model anyway, because you must keep the keys and
disclose them anyway when it gets to court.
Yes, the legally mandated stuff does really stuff up ones threat model :)
Okay, I agree to attribute some benefit to all-inclusive encryption, but
this is not the way, I believe, e-mail encryption success is to be
determined. This probably takes us back to the first message of the thread.
(If you have one of those, do you feel like
sharing it?? :)
I would if I had. :)
Yes. There is probably a pithy comment about ones threat models and security models changing the moment the first invoice gets paid :)
b. Above, there is point 5. For those who make
a risk management decision that they are concerned
with the MITM risk, they can simply phone up their
other contact and do a key exchange over the phone,
like as in PGP. The system covers the initial MITM
threat - it just asks you to do the heavy lifting
of the phone in the case where you need that.
Right, and this is why I like your method. This option is probably the
most useful one, but unfortunately, it brings us back to the
inconveniences of today's systems...
Well, it doesn't bring us back to the inconveniences
of today's systems, except in the 1% of cases where
people decide to do it.
...And I claim that this is the only 1% that counts... I guess this is
the root for the debate between us.
It may well be! In order to put meat on the debate, I claim to better serve the 1% by ignoring them!
I am just afraid of the 70% or so
of the 1/1E6 who will skip step 5 because of a false sense of
security...
Nah, 99% at least. And, they won't do it because
of a false sense of security. They'll do it because
of risk management - it isn't worth it to them to do
that step.
(They could be wrong of course. That's another story.)
I was more pessimistic - I did not say 70% but 70% of the 1/1E6...
Ah yes. You know, losing a bundle because of an email getting MITM'd is a better reminder than we can come up with.
c. You could make the case that there are people
that need MITM protection but don't know it. I
choose not to bother to protect those people,
because if they don't know, then they will do
something else which will compromise themselves,
such as install windows. (Not because I'm being
snarky or anything, just another risk management
decision.)
You see, but they (the MITM people) are your real customers, not the
masses.
?? I grant that if they were paying me, I'd
do something different. But they ain't. So
I won't.
You do it voluntarily, but you still do it for them... At least that's
how I see it.
(BTW, after realizing that they are 1/1E6, even if they were paying it
would probably not be worth it. :) )
Bingo! Once we really concentrate on those who are prepared to pay for it, we discover an awful truth about the market for security - they are too few to make it profitable.
So some other angle is needed.
That's why I basically stick to the mass market - because the honest paid market won't pay the bills, and the dishonest paid market is ... well, dishonest :P)
The masses don't need your e-mail encryption - they are fine
enough without it.
Yowsa! Where did this "need" thing come from?
It's not "need" but "lack of need" and it came from the observation that
nobody asked for e-mail encryption, nobody uses it (and don't give me
this usability excuse - people do things less "usable" than PGP when
they need to - like fighting with MS-Word indentation).
That's how it all started. Why don't people use encryption... Is it not
usable or do they just don't think they need it... I claim the latter.
The masses don't "need" the Internet, is that
what you mean?
The masses do need the Internet, at least the porn sites... :)
Funny story there - one thing that made SSL successful was porn. Over half of the early customers for certs were porn sites, and a disproportionate amount of the engineering forces came from them. This came from insiders; obviously, everyone in public played up the nice view that "ecommerce" was driving it, and not porn.
https://www.financialcryptography.com/mt/archives/000609.html
The to-be-MITM'ed guys, the ones who do send secrets
and who are subject to MITM may not know they have to fear MITM. They
are executives, lawyers, etc., and they do not even know what MITM is.
It *is* your business to bother with them because you are designing
their solution - they trust you and your security system (hopefully for
a pay :) )
Nope. It is their business to *pay* me for a
system, and advice. Until they do that, they
can go hang.
This brings me to my original claim that the rest don't need e-mail
encryption. They don't ask for it, and they don't use it. I agree that
your system is useful, and will lift the bar; I just don't think that
this is our main goal. The main goal are the people hanging above...
OK. Why is it the main goal?
(I admit I have no particularly impressive reason for "main goaling" the common masses.)
...
Right. So what is our goal?
Making security easier where strong security is needed. (not just
lawyers etc., also you and I when needing strong security for privacy or
business reasons).
Classically, we measure need by money. I think we can say that email has failed to generate enough need by that means.
Secure, being, completely and correctly covers those
things I choose to include.
I choose not to include "first MITM opportunity."
I also choose not to include "trojan on Windows OS."
And, there is no protection included for "meteors,
unicorns, sniper bullets."
And I'll argue certain threats are more likely than
others :)
I agree about the applicability of all claims but the MITM one of
course. If you don't mitigate unicorns, it's okay, because people don't
expect you to. However, if you don't protect against MITM in some modes,
these modes are not worth much (only to the masses, which is what I
don't count, and where we disagree).
That's an important point. Can we agree that the reason we protect against the MITM is because people expect us to?
This is why I said that regardless of my "concerns" I still think your
system should be deployed.
:-) Well, as I mentioned before, deployment is impossible. Sorry about that. I suppose it is evil of people to dangle such things around and then yank them back.
Where it is however very useful is to understand the model, because when we come to a greenfield situation we can deploy this model before the factors of resistance kick in. E.g., one reason Skype worked was because they did the work them selves, and didn't ask anyone's advice.
Now however if you go to email client suppliers, and explain this model, you'll be treated like Satan. It's too late for email.
We're supposed to design security systems for people who need it.
That's
at least what I do for a living...
Right, so we need to negotiate on goals.
Indeed...
Separate email.
The false sense of security is one of the
biggest boguss-arsed arguments ever used :)
It generally is imposed totally incorrectly.
It is easy to avoid a false sense of security.
You just state the security.
Easy. Done. End of story.
I actually agree with this.
False sense of security is not always such a big issue to resolve.
Unless it is falsely stated. For example, people often think that SSH suffers from a false sense of security but SSL doesn't. In practice it is exactly the reverse, and the claims indicate this.
The SSH weakness is open and in your face. Everyone knows that SSH has this weakness.
But the SSL weakness - exactly the same weakness of the MITM - is hidden, and pretended to be non- existance. It is in fact existant in the CA.
The CA is the TTP which is the centralised MITM point. All PKI did was move MITM from Alice+Bob across to Trent. It is this twist that has led to the SSL phishing attacks, which have surprised those with a false sense of security. e.g., the masses.
Now try telling people that PKI results in a false sense of security ...
I think that it is crucial that this one knows the limits of the
system,
because this one is the only one for whom the system is actually
useful.
If he doesn't get it - we got nothing. That's my opinion... (You don't
care about the one who needs security and I don't care about the 1E6
who
don't...)
Right. We have *different* definitions of
"secure" and different ideas about the market.
Yap.
Actually, I think we have different views only of the market. The
"secure" is implied from it.
Right. "Secure" is what we decide. Market is what we choose. Once we choose the market, we find the best definition of "secure." It's a marketing term.
iang

Message # 62

Date: Sat, 27 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

hi Hagai,
fun debate!
Hagai Bar-El wrote:
At 26/05/06 11:48, Ian G wrote:
There is some question about the relative benefits of
different philosophies of protection. I personally
sing to this rhythm:
do what you can for free,
then extend!
Call that 'A'. Others often set other targets. Many
love to dance to this tune:
Cover all threats in the set 'B'
coz the paying customers deserve it!
So why would we choose one over the other?
I trust I am your endorser for "Set B"...
I don't think we should choose one over the other. Having two modes
(with step #5 [Set B] and without step #5 [Set A]) is just great by me,
and that's what I keep saying from the start.
OK. In my rant, I'd say that is all Set A.
Set B is PKI.
The gap between these interpretations is very subtle, and that is part of the point.
For many many people, you are either in Set A or Set B.
You are not permitted to have both! You are especially not appreciated for showing how one can eat the other.
The case for set B is based on custom. The set of
threats included are those that have been selected
by an arcane and tricky process but let's assume
they are "good" for now.
The "tricky process" is called a threat-analysis.
I say not - which is why I called it a tricky process. The threat analysis in Set B is subverted to other things, which are mysterious.
I called that "custom" above but what I really mean is "means removed from easy analysis."
Here's more on what I mean:
http://iang.org/ssl/wytm.html
It may be called "threat-analysis," but it definately isn't threat analysis as we know it.
I think I was convincing enough about the ease of off-line MITM.
Even the dramatic spreading of open wireless nets has failed to show any statistical evidence that protocol-level MITM is a validated threat. Perversely, the only MITMs we know about is in the MITM-free browsing systems - phishing and DNS spoofing for same.
I say perversely, as what is holding back the response to that is the MITM-protections. If you talk to the browser people about fixing the MITM of phishing, you get the same response as if you suggest Set A in email clients.
The case for set A is based on economics. It walks
like this.
Free is defined to be something that is of lesser
or equal cost to the activity in question. Say we
are sending an email. Free means there is no other
activity or cost imposed on the sending of the email
other than ... already necessary in sending the email.
(See earlier mail!)
Now, if we assume away (rotate arms like windmills here)
the costs of implementation and deployment then that
means that all people on the planet of email could
have set A. For nothing.
Let's call that 99% of the emailing population.
Agreed.
The 99% get it for free. They don't necessarily need it, but they get
it, and since it's free, no one has any reason to object.
Right. And when they need it, it is there.
Oh happy day. And when they need real hard core heavy metal security, they can upgrade quite easily. Their cups runneth over.
Email over ROT13 is an incredibly secure system.
Not because the algorithm is secure; it isn't.
It's a secure system because it is _in place_ and upgrading an algorithm is trivial compared to putting a system in place.
What happens?
Well, I'm sorry to say that normal *business* processes
will kick in and totally destroy Set B. Completely
and utterly. No matter how much better it is.
Really? Like TABs destroyed SecureID? (LOL)
What's a TAB?
Like FedEx destroyed Brink's?
You mean, like the diamond industry? Where most diamonds are shipped in the regular post or by courier?
The thing about Brinks is that they are dealing with things that are *obviously* attractive and valuable.
Whereas, in email, we are agreed that this is very hard to determine in advance.
Like downloadable browser applets with PINs destroyed smartcards?
Smartcards destroyed themselves :) But that is getting closer if you are talking about transaction systems.
Many people need little security (or none). Some people need strong
security. Some products give low security (Set A) and some products, or
enhancements to the same products, give more security (Set B). These Set
B's can be and are sometimes orders of magnitude more expensive and they
still live; live well.
Right, why is that?
One of the difficulties here is that you are assuming that if we can just isolate the people who are prepared to pay from those who aren't, then we can simply deliver the goods to those former people.
Hence, "need".
It's not so easy - relating security needs to willingness to payment to market product is probably too inefficient a task given current knowledge to make it coherent. This is a specific observation on the security market.
If 99% of the people in the corporation use Set A,
then it will be the standard. It will be demanded
to be the basis of everything. It will become the
new lingua franca, the new way, the only way.
Verily, the definition of email.
Even if the corporation has a small group that needs
securing, they will simply use Set A and bolster it.
It is far more economic to bolster Set A than to
deploy Set B as well as Set A. They could even
layer Set B over Set A... if they so decide.
Right. In our case, Set B (steps 1-5) is a superset of Set A (steps 1-4)
that costs more (manual key management) and gives more. What's wrong?
Ah. Well, I'd say it is Set B *exor* Set A.
I'm talking about OpenPGP versus S/MIME here.
Or any PKI product versus any opportunistic product.
In that battle, you simply can't upgrade the opportunistic product to include the domain of the PKI product.
Set A of course does not *preclude* the features
in Set B. It just doesn't deliver them by default.
OTOH, Set B definately precludes the 99% usage
base that is available to Set A. There is no way
you can "reduce" Set B to cover the other 99%,
because to do so means either you require them
to pay (run away screaming!) or you need to break
your assumptions about customary security (crawl
in a hole and die!)
This is a system-design issue. Nobody said that a single product cannot
do both Set A and Set B and fall-back if this is desired.
No, it's a marketing issue. And yes, people do say that the single product can only do Set B, and you cannot fall back.
There is no fallback mode in SSL. In fact, the ADH protocol is considered to be "deprecated" in the RFC because it is "insecure". In OpenSSL it is turned off by default, not compiled, so it is simply not available in Apache. Because it is too dangerous for you to fall-back to it, you "might not know what you are doing."
If there was a fall-back, why do I need to install a certificate in my Apache in order to use secure browsing? Why isn't there a button on Thunderbird to generate a self signed cert and send it on its way? Why do browsers warn when I am using an expired certificate or a 40 bit cipher but not warn when I type my personal details into a HTTP form?
What's wrong with an expired cert anyway? What does it mean, "expired" ? Does RSA go off like milk?
Why is it that in SSL the user-certificate is demanded by the server, and not offered opportunistically by the client? Because such would be fall-back, and would allow a soft upgrade path.
For Set B there is no fall-back. And that's for rather excellent marketing reasons. The fact that it happens to *reduce* security is something we don't mention in polite circles. If we want a job, that is.
I don't get
your point. Even your own suggestion was a single system that supports
both (with or without step #5). I was only claiming that the "with step
#5" is no more usable than e-mail security today, and without step #5 is
not secure enough for most cases where security is needed.
See, you are already in the Set A camp - do what you can for free and upgrade. Welcome!
But this camp is in a knock-down fight with the Set B camp.
We know this to be true from experience. SSH
covers 100% of its market area - telnet is now
effectively only used for testing. Yet SSH has
this tiny known weakness.
Right, and I have no problem with that. I use SSH myself. I have no
problem because:
1. The MITM needs to be on-line, which is tough. In your case it can be
off-line.
2. I engage in the "risky" process once in five years, not once in a
month (when introducing a new correspondent).
SSH is nicely aligned to its threat model. That's no surprise, because it was developed in response to telnet sniffing - a validated threat. It did the threat analysis.
SSH actually went up against SSL-telnet. Not-
withstanding that SSL-telnet had some sort of
claim that it had "no weaknesses," it was trounced.
Not just trounced, it was destroyed, scattered to
the winds, blown into the milky way.
The reason was costs.
Cost-benefit, to be exact.
Sure.
SSL-Telnet gave too little added benefit for its added cost. I agree. I
would never use it.
The result was not pretty. Probably there are
only a handful of people who even remember that
SSL-telnet existed. And even fewer of those are
prepared to admit that they used it, briefly.
To be honest, I did not even know it ever existed...
Funny story - SSH caused connuptions in the PKI community because it was clearly evil and everyone agreed that it should be opposed. Unfortunately, it turned out that too many PKI people were actually using it to seriously stop it...
OTOH, we still have a situation where SSL is only
used in <1% of browsing. SSL claims complete
security, but it never broke out of 1% usage.
Maybe that's because only 1% of the browsing requires security...
LOL... that assumption again.
Don't forget that SSL does have it's cost in terms of performance.
I reject that claim, I don't forget it. It's just another hangover from the 1994 days when *certain* servers were having trouble. Guess which ones they were ;-)
Try and make the claim - it's only possible by reference to windmill arguments like high end ecommerce servers being overloaded.
(As if we care about a group that has the money to pay for the problem....)
(It's like saying, oh, let's not use SSH to transfer backups because that would be a waste. No, I regularly transfer gigabyte backups over SSH without caring a jot about performance.)
If
people don't need security they will not switch it on just because it's
there.
Right. And if they do need security, they will switch it off if it is inconvenient.
Kerchkfoffs' 6th again.
The only way to do it is to remove the switch, and make sure it is free as compared with any comparable product.
It has nothing to do with the design of SSL as requiring
certificates.
Fact is, even on the servers that support SSL and have the certificates
and all (added cost over SSH was already paid), most pages are not
encrypted even though it's a checkbox away with no extra cost.
Yup. Disaster for security. The security of SSL was practically destroyed by the separation into open and secure. Once
that was in place, it was almost impossible to secure the system in any simple fashion.
Prediction: if someone invented HTTP tunnelling
over SSH (of course, this is crazy talk), it
would wipe out SSL within 2 years.
Yeah, unless common browsers start caching self signed certificates.
I agree, that could save SSL. But that would be evil. The browser people would sooner drown kittens and eat babies than do that. They are Set B users.
However, even though SSH will kill SSL for its low setup costs, no more
than 1% of the pages will be encrypted, for the reasons I wrote above.
Why would you ever not use it? If it
was automatic... It works for Skype, it worked for SSH.
(Of course it is a hypothetical question, so details don't enter into it.)
The reason: coz SSH costs $0. Economics rules
over "security" whatever that latter word means.
"security", whatever the word means, is part of "economics" - they are
not ones against the other. This is what risk management is all about.
Right, I agree. The only security is that which is economic security.
And, "free" rules over "costs" no matter what the
threats.
I strongly disagree.
It's not true anywhere and it's not true in security, otherwise people
would still use passwords for the VPN's and not bother with HW tokens,
and there are dozens of other examples.
The SSL VPNs are taking over the VPN world, simply because they are easier to set up.
They are actually worse as they only cover small parts of the app set, where as the IPSec based VPNs "cover" all of the app set.
I *predict* that the SSH VPN will take over the SSL VPNs for the same reason. In each case security goes down in some theoretical measure, but security goes up simply because you get more of it.
The domination of SSH VPNs over SSL VPNs will be because the former is free, and the latter is mostly a paid product.
(I'm not really familiar with VPN market, and I'm interested to see whether these predictions take effect. It is rare that we get the chance to run the experiment. This is as close as we get to true science in the security game:
theory -> prediction -> experiment -> confirmation
)
iang

Message # 63

Date: Sun, 28 May 2006
From: "James A. Donald"
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

--
Ian G wrote:
Let's assume that the rant itself is plausible and the > conclusion - that Set A wipes out Set B in a fair > fight - is solid.
In which case, the only thing left is an unfair fight.
Set B, or the proponents thereof, have to basically > destroy Set A in *other* ways. E.g., ban it or > otherwise downgrade it so severely that it is treated > as "worse than any alternate."
Set B generates income for verisign, and therefore substantial handouts to writers of free browsers.
Set A does not have an economic model, except perhaps an open version A for the masses, and for pay version A' for businesses.
Observe that the creator of Bittorrent, the world's most heavily used software, is not making much money off it, even though it is turning the world of entertainment upside down.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
aEn5T5yzXdpehmGI9OATj62YQflVH6c8IjW8dPNJ
4VTKxCblBmZGd39jm+U7GJp+10KX20eq/eDHh8Ffb

Message # 64

Date: Sun, 28 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

--
Ian G wrote:
Now however if you go to email client suppliers, and > explain this model, you'll be treated like Satan.
It's too late for email.
I observed a similar resistance in SIP, where it is not too late. My impression was that they were supporting PKI for reasons unrelated to security - that it was somehow stuffed into the specification - and indeed, if they had their druthers, they would not bother with any security at all.
Security is hard, people tend to get it wrong (WEP and PKI) you cannot really test it into workability, because attacks do not manifest until widely deployed. You cannot tell the real experts from the bullshit artists by real world criteria. Therefore, if someone disagrees with orthodoxy, the rational response is to ignore him, even though orthodoxy is likely to be garbage, for the same reasons as it is rational to ignore those that disagree with orthodoxy.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
ql8miBlLBcYyERO2kjkGxpfn8a/6UIVGvEzm4Kdr
4ztOeMqHfH8gYT/xp2jBl8NAozJclkncSIMfHeSkD

Message # 65

Date: Sun, 28 May 2006
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

--
Ian G wrote:
No, it's a marketing issue. And yes, people do say > that the single product can only do Set B, and you > cannot fall back.
There is no fallback mode in SSL. In fact, the ADH > protocol is considered to be "deprecated" in the RFC > because it is "insecure". In OpenSSL it is turned off > by default, not compiled, so it is simply not > available in Apache. Because it is too dangerous for > you to fall-back to it, you "might not know what you > are doing."
(snip)
The basic design of PKI is to ensure that in order to use encryption, you have to pay Verisign for a certificate.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
w3lNXKQnRW2/nwzTvQkYb39ZEyKTILmWWtzwaPm4
4Or1iXz9IPdnqFBZIZhUbXAVv8ELLuVVZ+Fu+k3Dh

Message # 66

Date: Sun, 28 May 2006
From: Ian G
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

James A. Donald wrote:
--
Ian G wrote:
Now however if you go to email client suppliers, and
explain this model, you'll be treated like Satan.
It's too late for email.
I observed a similar resistance in SIP, where it is not
too late. My impression was that they were supporting
PKI for reasons unrelated to security - that it was
somehow stuffed into the specification - and indeed, if
they had their druthers, they would not bother with any
security at all.
Right. If you backtrack it all you might find some interesting forces. If telcos are involved, they will insist on PKI, not because they care, but other people are caring for them. If their are committees involved, it's a foregone conclusion.
https://www.financialcryptography.com/mt/archives/000609.html
(I know you've seen this one :)
Security is hard, people tend to get it wrong (WEP and
PKI) you cannot really test it into workability, because
attacks do not manifest until widely deployed. You
cannot tell the real experts from the bullshit artists
by real world criteria. Therefore, if someone disagrees
with orthodoxy, the rational response is to ignore him,
even though orthodoxy is likely to be garbage, for the
same reasons as it is rational to ignore those that
disagree with orthodoxy.
Yes. Having established orthodoxy, the mission is to keep it. The end result I think is that SIP will have trouble - not because of the PKI, so much, but because their willingness to adopt others' agendas means that the product will always be chained in the ways we've discussed in this group.
I use Skype myself. It is curious that they also adopted the CA center part of PKI. I would love to know whether there was a reason for that, it now stands as the big weakness, and we have some anecdotal evidence indicating that the weakness is already exploited.
iang

Message # 67

Date: Sun, 28 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all, and be back in time for tea
Cc: practicalsecurity at hbarel.com

Hello,
At 26/05/06 20:19, James A. Donald wrote:
Hagai Bar-El wrote:
Maybe that's because only 1% of the browsing requires
security... Don't forget that SSL does have it's cost
in terms of performance. If people don't need security
they will not switch it on just because it's there. It
has nothing to do with the design of SSL as requiring
certificates.
It has everything to do with its cost as requiring
certificates. It takes a skilled engineer half a day to
drop in a new certificate. Sites that do serious money,
such as the Gold Casino run for weeks with an expired
certificate, because introducing a new certificate is
frighteningly hard.
I was not saying that SSL deployment is not a pain. I know it is. I also realize it's expensive.
What I was saying is that the lack of deployment should be attributed not ONLY to deployment cost. Only 1% of the browsing is secured with SSL because of several reasons - one is certainly the cost of buying and installing certificates, but there are other reasons as well, such as the performance issues it introduces. Fact is, even on those servers that already have SSL certificates installed, and already have SSL enabled, most pages are not protected but only specific ones.
The cost of certificate explains why many servers do not use SSL. It does not explain why only few of the pages on SSL-enabled servers are actually sent over SSL.
Hagai.

Message # 68

Date: Sun, 28 May 2006
To: "James A. Donald"
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello,
At 26/05/06 20:29, James A. Donald wrote:
James A. Donald:
But if there is no existing relationship, there is
nothing to steal. We do not actually want to secure
true names. We want to secure true relationships,
which are represented by names, names that seldom
correspond precisely to true names.
Hagai Bar-El
Right, but if the establishment phase of a
relationship is also your
root of trust then it is not that meaningless anymore.
He has to keep the active attack going over a long
period while your relationship becomes valuable. If he
does this to any significant number of targets, his scam
will be detected before it yields anything of value.
Persistent active attacks are extremely vulnerable to
detection. Plus, it is simply hard to do. A persistent
active attack has to be done perfectly every time, over
a long time. By and large, the CIA is composed of
blundering idiots.
The CIA is not the only opponent, disregarding the competence of its employees. :)
An active attack is hard to sustain when it is indeed active. The attack here is not as active. It involves either planting a Trojan on a server, or periodically sampling POP3 mailboxes from outside. When we encrypt e-mail messages, this is partially what we encrypt the messages against.
It raises the bar beyond that achievable by the typical
Nigerian scammer, to levels that present a major
obstacle to the KGB and CIA.
But the KBG, the CIA, the FBI, and the IRS cannot
MITM an existing relationship which is all that they
are likely to want to MITM, if keys are routinely
and automatically exchanged, indexed, and archived
on setup of the relationship,
Hagai Bar-El
They cannot MITM an existing relationship, but they
can MITM when such starts.
But when it starts they will not know, the participants
generally will not know, that it is conspiracy to do
things that the CIA is interested in. If they
persistently MITM everyone, or even any substantial
number of people, or even one person in the entire world
for any lengthy period, they are going to be detected.
Maybe, and maybe not. They do not need a constant MITM, but just to sample mailboxes. Given you already accuse them for tapping each and every wire, this should not even be a problem. They can tell when a relationship is established and get into the mailbox (or actively MITM) just then.
The case in which they care about a relationship only after it is formed may occur, but does not reflect all cases. In some cases they may just as well be interested in a relationship as it is formed.
But forget the CIA, what about typical Trojans that sit on a server and sniff for new messages from banks, etc.?
Hagai.

Message # 69

Date: Mon, 29 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

Hagai Bar-El wrote:
Many people need little security (or none). Some people need strong
security. Some products give low security (Set A) and some products, or
enhancements to the same products, give more security (Set B). These Set
B's can be and are sometimes orders of magnitude more expensive and they
still live; live well.
One way to think of this is: which files do you back up?
Do you back up just the important files? The 1% you have to have?
Or do you back up everything?
Some people backup everything - because they couldn't be bothered working out which files to backup.
Some people backup only their "own" files, and they regenerate the system files. Or they backup "dailies" and "monthlies" separately.
But this only works because ... there is an easy way to determine what is important and what is not.
Same with email.
Is this post important? I don't know. I could hazard a guess that in a future life, those people on the evil practicalsecurity list will be hunted and gunned down in cold blood.
(If this were China ... If this were East Germany, when that existed ... If this were Iraq ...)
It's just so much easier to encrypt everything.
iang
Maybe that's because only 1% of the browsing requires security...
Don't forget that SSL does have it's cost in terms of performance. If
people don't need security they will not switch it on just because it's
there. It has nothing to do with the design of SSL as requiring
certificates.
Fact is, even on the servers that support SSL and have the certificates
and all (added cost over SSH was already paid), most pages are not
encrypted even though it's a checkbox away with no extra cost.
...
However, even though SSH will kill SSL for its low setup costs, no more
than 1% of the pages will be encrypted, for the reasons I wrote above.
(note to self!)
We have to address this issue of the
failure of websites to encrypt everything.

Message # 70

Date: Tue, 30 May 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email

Hagai Bar-El wrote:
Maybe, and maybe not. They do not need a constant MITM, but just to
sample mailboxes. Given you already accuse them for tapping each and
every wire, this should not even be a problem. They can tell when a
relationship is established and get into the mailbox (or actively
MITM) just then.
I think I agree in principle that idle pop boxes make for juicy targets. But I think that risk is low - the ISP is generally involved - for all low value targets. People, in other words.
For people who have more serious needs, well, we are agreed that they need to do more.
The case in which they care about a relationship only after it is
formed may occur, but does not reflect all cases. In some cases they
may just as well be interested in a relationship as it is formed.
How do you attack a relationship as it is forming?
Conceptually, it does seem to be a tricky thing. You would have to attack all such possibilities, and would end up generating a lot of chaff.
The reason that MITM is easy enough in principle is that you know the relationship exists, and you can watch it and decide on how and when and where.
So maybe a possible defence against 1st time MITMs is to throw out lots of false signals. (Not sure how to do that though.)
But forget the CIA, what about typical Trojans that sit on a server
and sniff for new messages from banks, etc.?
I wish they would. Then banks would then conduct proper relationship forming.
Over in Euroland they will shortly be rolling out new systems to bypass SSL security. It will involve the user *travelling into their branches* and 'personalising' (that is, forming a relationship) their mobile phones.
With this system in place, they will not need SSL at all.
(Well, I *think* that's the case, but it is conjecture, there are no published details on this as yet. I am sure they will continue to use SSL, but they won't need it.)
iang

Message # 71

Date: Thu, 01 Jun 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all, and be back in time for tea
Cc: practicalsecurity at hbarel.com

Hi,
At 29/05/06 20:14, Ian G wrote:
Or do you back up everything?
Some people backup everything - because they
couldn't be bothered working out which files
to backup.
Some people backup only their "own" files, and
they regenerate the system files. Or they backup
"dailies" and "monthlies" separately.
But this only works because ... there is an easy
way to determine what is important and what is not.
Same with email.
That's what I'm claiming. You know what is worth encryption and what is not.
Is this post important? I don't know. I could
hazard a guess that in a future life, those people
on the evil practicalsecurity list will be hunted
and gunned down in cold blood.
If it makes you feel any better, if this would ever be the case, I will probably go first... :)
It's just so much easier to encrypt everything.
The only point that is missing is that when encryption is "really" needed, this same method used for encrypting everything shall not be applied (this is the Set B part). So, Set A alone solves only the marginal part - those system files that are backed up.
At 30/05/06 00:25, you wrote:
Over in Euroland they will shortly be rolling out new
systems to bypass SSL security. It will involve the user
*travelling into their branches* and 'personalising'
(that is, forming a relationship) their mobile phones.
With this system in place, they will not need SSL at all.
(Well, I *think* that's the case, but it is conjecture,
there are no published details on this as yet. I am
sure they will continue to use SSL, but they won't
need it.)
They may still need SSL, or at least decide to use it. The personalization process will solve the need for certification of clients and possibly also of the server, but they will still need to form some secure authenticated channel, based on the credentials that they rolled out. They may, of course, rely completely on application-level security (secure the transactions and not the session) but they are not likely to be bald enough to do so...
My guess is that they would provision you with a nice X5.09 client certificate, and a trusted server certificate that will not pop up any unwanted dialog boxes, and use SSL on top of that... It's just a guess, considering that banks like to conform...
Hagai.

Message # 72

Date: Thu, 01 Jun 2006
To: Ian G
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] It is trivial to introduce secure email
Cc: practicalsecurity at hbarel.com

Hello again,
Sorry for taking time to respond.
I think that we're more or less in agreement on almost everything. I will just attempt to stand behind some of my words here.
At 27/05/06 14:02, Ian G wrote:
My logic is that people who need security usually need it for a reason
while people who just use it because it's automatic do not. A MITM is
not done for nothing - if an opponent does a MITM then it's for
something much more valuable than the typical random e-mail message that
can be picked up (and which you do protect).
I have to think about that for a bit, but here's
my intuition - it sounds dangerously circular. It
sounds like you would be saying that you are looking
for a market that truly appreciates the need for
MITM protection, and then you will be comfortable
specifying MITM to protect them, because they are
by definition needy for it.
What I was claiming is that I (Set B) protect the people who see MITM as part of their threat model, and thus I find myself obligated to address the MITM case. It is not circular, but you may claim that I am speaking of a null group of users, because no one cares about MITM. My claim was that some people do, and these are the people I protect. My chain of claims is: Some messages are worth more than the cost of a MITM (the cost of MITM is outside the loop - it's some constant for the purpose of our discussion), therefore: MITM is part of their threat model, therefore: MITM needs to be mitigated.
Try this pop quiz. If all your email was worth
$100 to you, would that make it worth protecting
at the "all" level, even if that left out some
protections such as MITM?
Or, at what point would you say, "ok, let's do
all of it?" $10? $1000?
It's a tough one, but the way I work today reflects that my answer is probably something quite low...
It's also tricky because it's not obvious what we mean by "protecting". A lot of the risk that may be worth it for me to mitigate is not something I can neither use Set A nor Set B to solve.
For example, you mentioned in another post the possibility that the PracticalSecurity guys will one day in the dark future be hunted down. No solution that we discussed here can help. The forum (as most others) is open to the public and the correspondence is sent to anyone who wishes and subscribes. It's also cached by at least one on-line archive, possibly more, and in general cannot be hidden. Even if we put Set A to use here, the evil guys would get access very easily.
Another big risk of e-mail is legal - if there is one thing I would "protect" all my messages against is being used against me in some legal dispute - this is something I cannot use Set A or Set B to protect against, because the mail is visible to the addressee, and also I may need to disclose my keys if the court asks nicely.
So, when we say that Set A (or any "Set" for that matter) "protects" all mail, we need to be careful in describing what it protects against...
Another is that it is possible to solve the "real"
security for the 99% once they have a system in
place - they just upgrade. So if you like, it can
be treated as a two-phase operation: First, give
them the free thing. Second, upgrade them to the
real thing.
I certainly agree. A foot in the doorstep is worth a lot here!
There is no risk for the masses, there *is* risk in the cases that are
worth a MITM, because they are the 1/1E6 that are worth it. I will try
to phrase it clearly: the great mass of e-mail messages do not care
about MITM, but they do not care about your system either, because they
have nothing at stake. The few messages that are at stake are also the
messages that are worth being MITM'ed, and you don't help them much
(well, you do, by step #5, but without improving the usability, which
was the problem at hand).
See above. Bear in mind that you are assuming that
there is zero threat to the masses - I would point
out that this is a convenient assumption, and isn't
really true.
Let's distinguish between zero-threat and "zero threat that can be mitigated by our system". As I pointed out, it's not that there is no threat, but some of the threat is such that we cannot help with.
I tend to agree that the threat is not a round zero, we're just disagreeing on whether the threat is worth it. And again, I see the Set A system (assuming it can be upgraded to Set B within its design) as a good idea; I was just pointing out that the user experience will not be improved where it most needs to, hence for the Set B people.
I believe that there is no damage in MITM because most people who write
e-mails that are worth a MITM, *do* use PGP or alike, or don't use e-mail.
Well, again, that's now drifting into self-selection
and circular logic.
That's my attempt at explaining why we never hear of any damage caused by sniffing of highly-sensitive e-mails. Considering the fact that e-mail is widely used for all sorts of information transfer, and considering the ease of attacks, and considering the fact that no mass-market e-mail security solution exists, I would expect many more news reports of incidents...
After all, I am sure you agree that *some* e-mails are worth the MITM (even if these are just 1/1E6). I still don't see them MITM'ed in the masses that they exist. You may be smiling and planning to use this as a proof that MITM is not a real risk, but since we know that it is technically feasible for some sum of money which is lower than the cost of some e-mails, then there is probably something else breaking the chain of loss.
Actually, it does not even say much about the practicality of MITM because getting someone's unprotected e-mail *today* (before your Set A is deployed) does not even require a MITM, and apparently people don't do it anyway...
My point was simply that usability dominates all.
If the system is unusable, it won't be used, and
messages will bypass the system. So the higher
goal won't be achieved; I think this is true
across all domains, but the details differ of
course.
There is certainly a point to it. I once complained to a friend of mine that I seldom use the apple-juice maker I bought, even though I love apple juice and the machine cost me a fortune. He told me something very clever: "The only criteria that determines the frequency of which you use kitchen appliances is the ease of cleaning them after use, period." What sounded at first as a gross over-generalization, occurred as very accurate when I actually measured it against the facts...
Yet, as much as I acknowledge your theory of usability - we need to determine what is the point in which something is "unusable" when it comes to security (or anything else). Locking and unlocking the door each time you get in and out is more inconvenient than using PGP and verify keys once a month, and you still do it. The door lock is inconvenient, but usable, because you understand why you do it. Same is e-mail encryption, I believe. The reason many people don't do it is because they don't think it's worth it for most of their e-mails, not because it is plain "unusable".
I wouldn't store a $100K value asset on Win32 either.
The point is that 1/1E6 messages are worth a lot (enough for a MITM -
the number in dollars doesn't matter) and the rest are worth zero.
I doubt that's sustainable! We simply don't know
which messages are worth a lot, a priori. Neither
does the sender.
(See case above. If you asked that opponent whether
her sex-chat was worth $1,000,000 before hand she
wouldn't have known what you were talking about.)
Okay, I claim that the cases in which you cannot know in advance that the message is worth a lot are the cases in which Set A/B cannot help anyway, such as in the legal case in which you are nailed one day by the addressee for something you wrote, or in case you write something to the public (e.g. forum) and the government decides one day that it does not like it, retroactively.
I am sorry, but I don't buy this sex-chat as a good case for "not knowing in advance" because I claim that this woman falls in the criteria you defined once of the people who just cannot be helped and thus shouldn't. Ian, if you were running for some public position, and you were having some private possibly-embarrassing correspondence at that time, would you set for less that Set B protection? I wouldn't.
...And I claim that this is the only 1% that counts... I guess this is
the root for the debate between us.
It may well be! In order to put meat on the debate,
I claim to better serve the 1% by ignoring them!
...But they are the ones that most need to be served. They are the problem! :) Okay, we're going in circles here. I think we understand each other's point by now... ;)
You do it voluntarily, but you still do it for them... At least that's
how I see it.
(BTW, after realizing that they are 1/1E6, even if they were paying it
would probably not be worth it. :) )
Bingo! Once we really concentrate on those who are
prepared to pay for it, we discover an awful truth
about the market for security - they are too few
to make it profitable.
This may be true, I am not completely sure. I am still making a living for the time being...
That's why I basically stick to the mass market -
because the honest paid market won't pay the bills,
and the dishonest paid market is ... well, dishonest :P)
...And what bill is the mass market paying? I think James has mentioned the poor Bit-torrent author...
I agree about the applicability of all claims but the MITM one of
course. If you don't mitigate unicorns, it's okay, because people don't
expect you to. However, if you don't protect against MITM in some modes,
these modes are not worth much (only to the masses, which is what I
don't count, and where we disagree).
That's an important point. Can we agree that
the reason we protect against the MITM is because
people expect us to?
Yes, and they expect it for a reason (to my opinion), at least the one who really need this security.
Now however if you go to email client suppliers,
and explain this model, you'll be treated like
Satan. It's too late for email.
I'm afraid so...
Unless it is falsely stated. For example, people
often think that SSH suffers from a false sense
of security but SSL doesn't. In practice it is
exactly the reverse, and the claims indicate this.
The SSH weakness is open and in your face. Everyone
knows that SSH has this weakness.
But the SSL weakness - exactly the same weakness
of the MITM - is hidden, and pretended to be non-
existance. It is in fact existant in the CA.
The CA is the TTP which is the centralised MITM
(snip)
Right. Presumably, if the CA is doing a good job, then it handles the MITM off-band. However, "doing a good job" breaks their business model (how much can you possibly charge for a lousy certificate), so they revert to poor off-band mechanisms (poor = non-existent), which makes everything you say true. Add this to the bad naming mechanism, and so on... Indeed, public PKI out-of-the-box does involve a large false sense of security.
Hagai.

Message # 73

Date: Fri, 02 Jun 2006
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Why we can propose weakness, dominate all,

Hi all,
Hagai Bar-El wrote:
That's what I'm claiming. You know what is worth encryption and what is
not.
Well. I'm claiming the opposite! It is true that if we sat down and thought about it, I would be able to give an *estimated encryption desirability* for any given email. But basically, I'd rather not bother. I'd rather encrypt them all, and have computers do the hard work for me. They are after all intended to do the boring tasks, and I'd rather not calculate things that aren't worth calculating, if I can find a way to do that.
Is this post important? I don't know. I could
hazard a guess that in a future life, those people
on the evil practicalsecurity list will be hunted
and gunned down in cold blood.
If it makes you feel any better, if this would ever be the case, I will
probably go first... :)
Heh:) If you are in america, you're already plea bargaining with the user list!
It's just so much easier to encrypt everything.
The only point that is missing is that when encryption is "really"
needed, this same method used for encrypting everything shall not be
applied (this is the Set B part). So, Set A alone solves only the
marginal part - those system files that are backed up.
Oh, right. Sure. It solves the "marginal" part.
Then, when we really do want it, we move to the "extended" or Part 5 case. Which happens to be easy, because it is just an extension.
Or so the logic goes. And then add in the economics, and it is a slam dunk. SSH and to a lesser extent Skype showed that this is the way to do it.
At 30/05/06 00:25, you wrote:
Over in Euroland they will shortly be rolling out new
systems to bypass SSL security. It will involve the user
*travelling into their branches* and 'personalising'
(that is, forming a relationship) their mobile phones.
With this system in place, they will not need SSL at all.
(Well, I *think* that's the case, but it is conjecture,
there are no published details on this as yet. I am
sure they will continue to use SSL, but they won't
need it.)
They may still need SSL, or at least decide to use it. The
personalization process will solve the need for certification of clients
and possibly also of the server, but they will still need to form some
secure authenticated channel, based on the credentials that they rolled
out. They may, of course, rely completely on application-level security
(secure the transactions and not the session) but they are not likely to
be bald enough to do so...
Right, I'm sure they will continue to use it, absolutely.
I'm just arguing that they won't *need* it anymore, in that their original core rationale for needing it and deploying it will have disappeared.
The thing about the marginal privacy aspects is that in the absence of any other factors I doubt they would have bothered to employ SSL for that. Now it's there, it will operate under momentum for some time, until they either discover a new reason or it fades away over time.
My guess is that they would provision you with a nice X5.09 client
certificate, and a trusted server certificate that will not pop up any
unwanted dialog boxes, and use SSL on top of that... It's just a guess,
considering that banks like to conform...
No, that's all too hard to deploy in principle. Although I have no hard data - nobody really talks about it unless bribed - everyone who has tried client side certs has dropped it when convenient. There are design failures in client side certs - the normal obvious ones - such that it is non-economic in principle, just no ROI.
iang


© Design By Mike East