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,But ... people use encryption in Skype. And all users of SSH face a slightly complicated interface, and always use it.
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...
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
Hello,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.
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.
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 allPeople 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.
users of SSH face a slightly complicated interface,
and always use it.
The advantage that those tools have is that there isI agree. Whenever this can be done this is certainly the way to go.
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.
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 ...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.
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 mixYes. 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.
secure modes with non-secure mode.
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 doYou 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.
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 isThis 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.
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.
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 usersBut it is only slightly complicated. Setting up encrypted email, or setting up an https server, is hellish.
of SSH face a slightly complicated interface, and
always use it.
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,The problem is characterised by Kerckhoffs' 6th principle, being:
At 07/05/06 22:01, Ian G wrote:
But ... people use encryption in Skype. And allPeople use encryption in Skype, as you pointed out, because they have no
users of SSH face a slightly complicated interface,
and always use it.
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.
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.
In that case, I humbly submit that such systems will suffer poor security, because the users will just turn it off. Why bother?The advantage that those tools have is that there isI agree. Whenever this can be done this is certainly the way to go.
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.
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.
(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.)
Make them both secure all the time. It's much easier that way. IMO, the "need" for an insecure usage is much exaggerated.Email crypto of course faces a separate problem ...I think so too. As long as secure e-mail clients need to interoperate
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.
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 mixYes. In general, I think that "security level" is an attribute that
secure modes with non-secure mode.
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)
(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:
--Right. It works.
Ian G wrote:
But ... people use encryption in Skype. And all usersBut it is only slightly complicated. Setting up
of SSH face a slightly complicated interface, and
always use it.
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 AWell, 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?"
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 installYup!
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 theActually, you have it backwards - e-gold was the company in Nevis, and G&SR is incorporated in FL.
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)
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: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.
In that case, I humbly submit that such systemsThe advantage that those tools have is that there isI agree. Whenever this can be done this is certainly the way to go.
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.
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.
will suffer poor security, because the users will
just turn it off. Why bother?
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 anTake 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.
example where there are significant costs, and the
user must be given a choice.)
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 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".I think so too. As long as secure e-mail clients need toMake them both secure all the time. It's much
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 mixYes. In general, I think that "security level" is an attribute that
secure modes with non-secure mode.
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.
easier that way. IMO, the "need" for an insecure
usage is much exaggerated.
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: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.
In that case, I humbly submit that such systemsThe advantage that those tools have is that there isI agree. Whenever this can be done this is certainly the way to go.
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.
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.
will suffer poor security, because the users will
just turn it off. Why bother?
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 anTake 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.
example where there are significant costs, and the
user must be given a choice.)
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 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".I think so too. As long as secure e-mail clients need toMake them both secure all the time. It's much
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 mixYes. In general, I think that "security level" is an attribute that
secure modes with non-secure mode.
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.
easier that way. IMO, the "need" for an insecure
usage is much exaggerated.
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.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.
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.
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 forThis 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.
free with contact list and alias management.
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:
( 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. )What we tend to forget is that even though the "poorly trained gruntI agree. Whenever this can be done this is certainly the way to go.In that case, I humbly submit that such systems
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.
will suffer poor security, because the users will
just turn it off. Why bother?
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 switchI 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?
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)
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 publicNo, 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.
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.
Skype, et al, on the other hand does not rely on that assumption.
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.(It would be apropos at this point to bring in anTake a P2P (hence, non-server-based) system that secures IRC messages
example where there are significant costs, and the
user must be given a choice.)
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)
When I chat about tea recipes with someone I don't know over IRC in aRight. But that proposal is based on a sense that only a voice-confirmed key is worth it in our security model.
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.
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 willOh, there are lots of flaws with those systems.
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.
But some flaws are just strawmen. Repudiability is one such.
I agree that security comes for no cost at most times, and thus there isWell, 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.
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...
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::) The answer is, there is soooo much to unlearn.
Security should have near zero cost. It should come forThis seems to be the general consensus, but the more often I see it
free with contact list and alias management.
repeated, mantra-like, in security mailing lists, the more confused I am.
The very notion of security depends on a threat model. To demand thatWell, if one stops there, yes :)
"security" have near-zero cost independent of the threat model is akin
to demanding world peace.
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 costCouldn'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.
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)
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. canThe 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.
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?
PS: I find Enigmail integration into Thunderbird very painless and veryI must try it!
convenient.
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:
Stephan Neuhaus wrote:Security should have near zero cost. It should come > > for free with contact list and alias management.
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:
--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.
Hagai Bar-El wrote:
What we tend to forget is that even though the "poorlyI observe that I continually receive genuine, but
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.
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)
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 needsI 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.
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?
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.Take a P2P (hence, non-server-based) system thatNo he does not. His client does.
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.
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:
--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.
Hagai Bar-El wrote:
What we tend to forget is that even though the "poorlyI observe that I continually receive genuine, but
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.
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)
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 needsI 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.
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?
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.Take a P2P (hence, non-server-based) system thatNo he does not. His client does.
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.
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:
--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.
Ian G wrote:
This is the old "SSH flaw" - in theory anyone can doMITM on the first setup is very low risk, because on
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.
first setup, there is not much worth stealing, and
because there are not that many first setups.
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 phishingYes - 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.
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.
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
...particularly over wireless networks. especially at conferences and other venues where targets congregate...
MITM in general is quite high risk
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. DonaldThe possibility is ... plausible. The risk is another matter.wrote:
...particularly over wireless networks. especially at conferences and
MITM in general is quite high risk
other venues where targets congregate...
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
...i have seen these attacks* first hand for the purposes of: - ssh login interception for gathering zombies / shell accts / data.
Is there any evidence yet of wireless MITMs for
gain?
- 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 anecdotali'd love to see a good analysis for various environments where wireless is popular.
reports have increased over the last few years.
(I generally discount techie conferences wherefair enough. these kinds of attacks should be expected at security / hacker conferences i suppose.
"laboratory conditions" are assumed or prevail.
I also discount hacking into users' systems, asi've seen a lot more of these exploit / penetrate attacks against users on the same wireless hotspot or within range of injection attacks.
that's a system crack not an MITM.
There is athis too, via active attacks. this is also more like a crack as mentioned above than a MITM.
bit more evidence that people are using open
wireless to access business systems to steal
data.)
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 forGerman authorities are developing tools to capture IP traffic from suspected offenders using MITMs. It could even be that these tools are already in use.
gain?
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: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).
Is there any evidence yet of wireless MITMs forGerman authorities are developing tools to capture IP traffic from
gain?
suspected offenders using MITMs. It could even be that these tools are
already in use.
(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:
--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.
Hagai Bar-El:
for this to be really useful, some real identityBut "real" identity is not useful, for there are no true
should be set behind the client.
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 trustedPeople trust nyms, not identities. What is a brand name
server to initially bind names to keys. An SSH-model
would work, but still omits the actual user identity
from the security model.
but a nym?
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: WeIn 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...
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.
Banks and credit card companies are indeed not one-time, but they do not and will not adopt an SSH-style "relationship tracking" either.Sometimes it's good enough - something it's not. ForWhat we urgently need to protect are communications from
example - if the communication is one-time in nature
then trusting the key once and caching it does not add
much.
our banks, employers, credit card companies, Amazon, and
ebay - none of which are "one time"
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 isI am not too much aware of Zokoo's triangle system, but will gladly look into it. Thanks for pointing it out.
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.
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: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".
The fact that most people don't bother to switchI think I mildly disagree with that hypothesis,
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.
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 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 threatRight, 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.
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)
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, and always had, that systems that are made for the publicNo, it doesn't make it insecure, but it does mean
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.
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 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.
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.Well, I would simply exchange the public keys as(It would be apropos at this point to bring in anTake a P2P (hence, non-server-based) system that secures IRC messages
example where there are significant costs, and the
user must be given a choice.)
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.
part of the protocol and use them. Create a sense
of key-relationship, by recording how many times it
is seen. Allow external verification.
It also assumes the initial session is secure.
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.When I chat about tea recipes with someone I don't know over IRC in aRight. But that proposal is based on a sense
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.
that only a voice-confirmed key is worth it in
our security model.
However, trusting a key just because this is the key you saw before is not always suitable.
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 agree that security comes for no cost at most times, and thus there isWell, true. It is important to define our
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...
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 nationalI agree. :)
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 generallyRight, 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.
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 baseI agree. Skype gives a good starting point, and e-mail gives zero.
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.)
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:
--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.
Hagai Bar-El:
for this to be really useful, some real identityBut "real" identity is not useful, for there are no true
should be set behind the client.
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 trustedPeople trust nyms, not identities. What is a brand name
server to initially bind names to keys. An SSH-model
would work, but still omits the actual user identity
from the security model.
but a nym?
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: WeIn 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...
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.
Banks and credit card companies are indeed not one-time, but they do not and will not adopt an SSH-style "relationship tracking" either.Sometimes it's good enough - something it's not. ForWhat we urgently need to protect are communications from
example - if the communication is one-time in nature
then trusting the key once and caching it does not add
much.
our banks, employers, credit card companies, Amazon, and
ebay - none of which are "one time"
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 isI am not too much aware of Zokoo's triangle system, but will gladly look into it. Thanks for pointing it out.
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.
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: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".
The fact that most people don't bother to switchI think I mildly disagree with that hypothesis,
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.
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 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 threatRight, 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.
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)
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, and always had, that systems that are made for the publicNo, it doesn't make it insecure, but it does mean
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.
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 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.
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.Well, I would simply exchange the public keys as(It would be apropos at this point to bring in anTake a P2P (hence, non-server-based) system that secures IRC messages
example where there are significant costs, and the
user must be given a choice.)
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.
part of the protocol and use them. Create a sense
of key-relationship, by recording how many times it
is seen. Allow external verification.
It also assumes the initial session is secure.
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.When I chat about tea recipes with someone I don't know over IRC in aRight. But that proposal is based on a sense
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.
that only a voice-confirmed key is worth it in
our security model.
However, trusting a key just because this is the key you saw before is not always suitable.
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 agree that security comes for no cost at most times, and thus there isWell, true. It is important to define our
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...
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 nationalI agree. :)
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 generallyRight, 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.
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 baseI agree. Skype gives a good starting point, and e-mail gives zero.
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.)
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
...good usability is hard. secure usability is hard squared. :)
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.
... or to crack thruweak 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.
a weakness in the endpoints.
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 beenit's probably the hardest path. i suspect if you close the phishing holes and harden the endpoints it would suddenly become much more popular.
used to justify all sorts of nonsense - yet we
still have no viable statistics on actual use
in the wild.
phishing and exploits are the best investment by far because they are so easy and so effective.
Meanwhile, the phishing styletoo 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?
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-MITMas long as phishing and vulnerable endpoints exist i would agree.
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.
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 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.
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".
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 forWell, I disagree there :)
where automatic security is much harder to introduce.
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
...but only if the initial exchange was MITM'd and cached Eve's bogus key.
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.
Such attacksthis would be awesome; please implement!
are just kneejerk reactions to the
discovery that there are different
ways to approach this problem - the
attacks have no founding.
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 GRight, silly risk really.wrote:
...but only if the initial exchange was MITM'd and cached Eve's bogus key.
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.
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 thisSuch attacksthis would be awesome; please implement!
are just kneejerk reactions to the
discovery that there are different
ways to approach this problem - the
attacks have no founding.
much much better than current state with almost zero risk.