e2e & security by default (Re: e2e all the way)

[Adam Back]

OK summing up: I think e2e secure, and secure by default.

On Fri, Aug 26, 2005 at 04:17:32PM -0400, Steven M. Bellovin wrote:
> 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.

I think user-to-server "security" is not secure by in my view the most
important comms security metric -- e2e security.  So if one engineers
for this as the default your system becomes not secure by default.

Don't forget that peoples security model can change radically without
warning.  (end users) typically give no prior thought to security
until something goes wrong.  At which point they are screwed if the
default is "secure comm to the UTP".

People complain at microsoft for example, if their software is not
secure by default.  The BSD OS goes to some pains to be secure by
default.

If you're saying yes it _could_ be e2e secure if users jump through
x,y,z hoops (like run your own IM server!) ... well you know that even
power users, who do want security, may give up at the inconvenience of
that.

> >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?

I draw the line for IM security:

- private keys generated on the client
- public keys maybe by default certified by central entity
  - but advanced user has choice to use other ceritfication, including
    out of band, WoT etc
(central entity one can easily automate, which is what skype does)

now a-kind of active MITM with rogue CA attack is possible with
collusion of the central CA (by issuing a second certficiate for the
wire-tapping party), however the advanced user can detect and come
away with evidence of this.  The fact that the advanced user retains
this ability I think adds value for even non-technical users; the CA
run risk of ruining their reputation, violating the CPS etc. and of
their being evidence.

btw I think there is signifciant additional value in _forceing_ the
attacker to sniff the traffic *and* do an active MITM with rogue CA
attack.  With your by default route through UTP, the attacker has a
natural and convenient place to subpeona, OS penetrate etc. and
undetectably snoop on traffic.

> 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?

I used key roaming in this scenario when I had this problem.  (Without
giving the central server cleartext private key).

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

I disagree.  My metrics for secure IM protocol design are:

- private keys are generated on client machine
- private keys do not leave client machine in unencrypted form
- end2end security where possible
- immediate forward secrecy where possible

And you can do auth-key roaming in this.

(Note for IM security you are better off certifying auth keys and
using the auth keys to authenticate EDH; if the user forgets the
password etc., you can just issue new auth certs).

If you've looked at IM security, there are a number of other
interesting challenges in IM security also btw, joining and leaving
security, and the fact that comms group can be > 2 endpoints.  Joining
and leaving security argue for backward secure and forward secure
re-keying respectively.

Adam

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