e2e all the way (Re: Another entry in the internet security hall of shame....)

[Steven M. Bellovin]

In message <20050826175947.GA18268 at bitchcake.off.net>, Adam Back writes:
>On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
>> In message <20050826082432.GA1797 at bitchcake.off.net>, Adam Back writes:
>> >Thats broken, just like the "WAP GAP" ... for security you want
>> >end2end security, not a secure channel to an UTP (untrusted third
>> >party)!
>> >
>> 
>> What is security?  What are you trying to protect, and against whom?
>
>Well I think security in IM, as in all comms security, means security
>such that only my intended recipients can read the traffic.  (aka e2e
>security).
>
>I don't think the fact that you personally don't care about the
>confidentiality of your IM messages should argue for not doing it.
>Fair enough you don't need it personally but it is still the correct
>security model.  Some people and businesses do need e2e security.  (It
>wasn't quite clear, you mention you advised jabber; if you advised
>jabber to skip e2e security because its "too hard"... bad call I'd
>say).

On the contrary -- I did say that I support and use e2e security.  I 
simply said that user-to-server security solves a lot of many -- most? 
-- people's security needs.
>
>> Do I support e2e crypto?  Of course I do!  But the cost -- not the
>> computational cost; the management cost -- is quite high; you need
>> to get authentic public keys for all of your correspondents.  That's
>> beyond the ability of most people.
>
>I don't think it is that hard to do e2e security.  Skype does it.
>Fully transparently.

Really?  You know that the public key you're talking to corresponds to 
a private key held by the person to whom you're talking?  Or is there a 
MITM at Skype which uses a per-user key of its own?
>
>Another option: I would prefer ssh style cached keys and warnings if
>keys later change ("opportunistic encryption") to a secure channel to
>the UTP (MITM as part of the protocol!).
>
>Ssh-style is definitely not hard.  I mean nothing is easier no doubt
>than slapping an SSL tunnel over the server mediated IM protocol, but
>if the security experts are arguing for the easy way out, what hope is
>there.  I'm more used to having to argue with application
>functionality focussed people that they need to do it properly -- not
>with crypto people.
>
I'm not arguing for the easy way out; I'm saying that security is an 
engineering matter, and that there are tradeoffs, including in the 
human factors.  People who click "yes" to every download aren't going 
to understand when to accept a key change notice.  Btw, I regularly 
use 3 different machines when talking to my Jabber server.  Is your 
client going to cache all 3 keys for me?  Will all of my correspondents 
know when to click "yes" and when not to?  My son sometimes uses AIM 
from public web browsers.  What then?

I'm sure you're itching to type that my keying material should be on a 
smart card of some sort, so that I could carry it with me and use the 
same key from any machine I choose.  If so, you'd be 100% right.  I'll 
note that for about 99.99% of people, that's just not feasible; they 
don't have a smart card and their OS doesn't have an interface that 
makes it easy to do the right thing.  Heck, I don't have a smart card; 
I don't even know of any smart card readers that talk properly to 
NetBSD, my OS of choice.

Here's the problem for a protocol designer.  You want to design a 
protocol that will work as securely as possible, on a wide range of 
platforms, over a reasonably long period of time.  What do you do?  If 
you engineer only for e2e security, you end up in a serious human 
factors trap (cue "Why Johnny Can't Encrypt" and Simson Garfinkel's 
dissertation).  Instead, I recommend engineering for a hybrid scenario 
-- add easy-to-use client-to-server security, which solves at least 75% 
of most people's threats (I suspect it's really more like 90-95%), 
while leaving room in the protocol for e2e security for people who need 
it and/or can use it, especially as operating environments change.  
This is precisely what Jabber has done.

To sum it up in one sentence: "design for the future *and* the present".


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



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com