Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
Ian G wrote: Steven M. Bellovin wrote: 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. Almost certainly though, the authorities of whatever government holds a VoIP hub are going to start insisting that traffic is interceptable at that hub. of course with SIP, unless you are proxying both ends, you are doing direct client-to-client links anyhow (so any crypto must be e2e, by definition); again however, unless there is some sort of PK retention in place, mitm attacks and attacks on the initial key negotiation are possible. - 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....)
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....)
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]
Re: e2e all the way (Re: Another entry in the internet security hall of shame....)
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
e2e all the way (Re: Another entry in the internet security hall of shame....)
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).
> 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.
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 do think we have a duty in the crypto community to be advocates for
truly secure systems. We are building piecemeal the defacto privacy
landscape of the future; as everything moves to the internet. Take
another example... the dismal state of VOIP security. I saw similar
arguments on the p2p-hackers list a few days ago about security of p2p
voip: "who cares about voice privacy" etc.
Adam
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
