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

2005-08-27 Thread Ian G

Steven M. Bellovin wrote:

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?


yes, this is the optimisation that makes Skype work,
it is (probably) vulnerable to an MITM at the center.

This is a tradeoff.  What it means is that the center
can do an active attack.  But it can't do a passive
attack (this is speculation but it seems reasonable
or at least achievable).

That's a good deal for users, when you consider their
alternative.  Fantastic value for money, really, it's
really very hard to criticise...


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,


The evidence suggests that if you just slap an SSL
tunnel in place, you end up with an ongoing mess of
key management - ref - what this thread started with
from google.  If you do the thing properly, and
build it opportunistically, with the option of
upgrading to signed certs for those that really
want that, you can avoid all that.  But few do, for
some reason, or maybe those successful cases we just
never hear about because they work without fuss...

When SSL is your hammer, everything gets nailed as
a server.


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.


On this I think we'd all agree.  Although I'd also
add that it should be economic - if it doesn't deploy
then it does not good.

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.


It's fascinating that you see this and I wish you'd
share the threats you see.  I see only node threats,
you see only wire threats.  Why is this?

(I can quote reams and reams of news articles that
point to merchant data losses and PC malware and virus
attacks... but it would be boring.  Just ask Lynn for
his feed ...)

My view of the p2p threat model:

  other party - 70%
  own node- 20%
  center  - 10%

To an accuracy of +/- X%.  Obviously, the wire
threats - that are protected by Jabber's SSL and the
like - are in the noise somewhere there (but I expect
them to get much more aggressive in the future).

Another way of looking at this is to ask what the damage
is.  If your chat traffic is breached by some random
threatening outsider, what does he gain?  Nothing, so
it doesn't take a PhD to realise nobody's interested.
But if your listener is a *related* other party and
has your messages, then that's a whole other story...
This is why for example the most popular IM security
system is the discarded nym.


iang

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


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

2005-08-26 Thread Peter Saint-Andre

Adam Back wrote:


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).


No one advised any such thing, and e2e was a requirement addressed 
within the IETF by the XMPP WG, resulting in RFC 3923.


Peter



smime.p7s
Description: S/MIME Cryptographic Signature


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

2005-08-26 Thread Steven M. Bellovin
In message [EMAIL PROTECTED], Adam Back writes:
On Fri, Aug 26, 2005 at 11:41:42AM -0400, Steven M. Bellovin wrote:
 In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED]