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

[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 majordomo at metzdowd.com