Re: ZRTP comments part 4: security (everything but SAS)

[EKR <ekr@xxxxxxxxxxxxxxxxxxxx>]

Craig Southeren <craigs@xxxxxxxxxxxxxxxxx> wrote:

> On Sat, 17 Mar 2007 02:35:21 -0700
> EKR <ekr@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> ..deleted
> 
> > > Let's assume Alice has a certificate that is not signed to a specific
> > > domain name, meaning it it is being used to authenticate a person, not a
> > > device. Making that cert transportable seems very insecure - anybody
> > > who can get my cert becomes me until I revoke it. 
> > 
> > I assume that by "cert" transportable, you mean "private key".
> > Certificates are public information. Moreover, as I said
> > in a recent reply to Alan, it's important to not get hung up
> > on certificates. Keys are what's important here. There's no
> > reason why the certificate can't contain any random name in it
> > you want, including "This is not a name."
> 
> Such a certificate would be hard for a user to validate the first time
> it was presented. How is Bob supposed to know that a certificate
> labelled "This is not a name" actually contains a valid key for Alice?

How is Bob supposed to know that the person on the other end of
the ZRTP channel is Alice? As I noted previously, DTLS could quite
well be used with an SAS (though our normal answer is to trust
the signalling) see S 8 of draft-fischl-sipping-media-dtls-02 for 
more on this.


> If I use the same key in all of my phones, and I lose my cell phone,
> then I have to revoke the single key used by all of my devices. That's
> damned inconvenient - especially if I'm overseas and I revoke the key
> used by my answering machine still at home.

Sure. And nobody is going to make you do use the same key.
My point is that doing so is an option with a static key
but it's not with the mechanism used in ZRTP.


> > > and can get lost in disk
> > > crashes or be un-cached just as easily as any other information.
> > 
> > Yes, but they're static. Consider the following sequence of events.
> > 
> > 1. Alice installs software.
> > 2. Bob calls Alice.
> > 3. Alice takes a backup.
> > 4. Bob calls Alice 
> > 5. Bob calls Alice.
> > 6. Alice has a disk failure and restores from the backup pulled 
> >    at time (3).
> > 7. Bob calls Alice.
> > 
> > In a static system, the data restored from backup will allow Alice
> > to authenticate to Bob even after the crash. However, because
> > the key continuity mechanism in ZRTP evolves with every call,
> > Alice's state at time 6 during the time of the crash will not
> > match her state at time 3 when the backup was taken and Bob and
> > Alice will discover their secrets don't match. 
> 
> Every system will have a worst case sequence of events. 
> 
> For a cert based system, the worst case occurs if Bob issues a new cert
> with a new key after Alice takes her backup. After Alice restores, she
> will have to re-accept the new cert from Bob as the new key's
> fingerprint won't match his old one. 

Yes, but this worst case applies equally to the key continuity
mechanism used in ZRTP. By contrast, the case I outlined above
does not occur in static key based systems.



> > > If Alice calls Bob from a different endpoint that uses a auto-generated
> > > self signed cert then Bob will get the same sort of prompt as an SAS.
> > 
> > Yes. The point is that static keys can be run in either mode, whereas
> > the key continuity mechanism described in ZRTP can be run in only
> > one.
> 
> I'm not sure I understand your point. Can you explain further?

Sure.

With any system that has key continuity, you can have cases where you
encounter a new device and you have to re-inititate the authentication
cache. If you use the mechanism in ZRTP, then this happens *every*
time the user introduces a new device. If you use a mechanism based
on static keys you can either (1) have a separate key per device
or (2) share keys between devices. In the second case you won't get
a prompt when a new device is introduced.


> > > People are conditioned *right now* to clicking straight though warnings
> > > about certificates on web sites. I saw my son do it last night because
> > > the secure email web site for his nationally respected university was
> > > using a self signed cert, and he was using my laptop which had not
> > > accessed that site before.
> > 
> > Yep. This is a serious concern with any system that requires manual
> > intervention to decide whether authentication is OK--which is one
> > reason why people have concerns about SAS as a security mechanism.
> 
> My point is that the same concern applies to approving certs.

Absolutely.


> > > Why is this different from clicking through an SAS prompt? 
> > 
> > It's not different in kind, but it is different in degree because
> > the particular design of the key continuity mechanism means that
> > it will happen more frequently and so people will have an even
> > lower bar (if possible) to ignoring this kind of authentication
> > warning. What I'm pointing out is that it's possible to design
> > key continuity mechanisms that don't have this property.
> 
> ZRTP allows you to specify the cache timeouts in the Confirm message
> exchange. Section 5.5 states "A value of 0xffffffff means the secret
> should be cached indefinitely and is the recommended value"

Yes, but there doesn't seem to be a hard requirement that you never
forget or that you treat a peer forgetting as a security error.
And because there are lots of legitimate ways for the caches to
get out of sync, that's the only reasonable thing to do. But this
makes it easy for an attacker to *pretend* that they're the real
person and have forgotten the secrets (or are on a new handset)
and just do a new SAS with you. Because this is a reasonably common
and legitimate event, this diminishes the usefulness of the key 
continuity mechanism under active attack.


> To me, a cert provides a "one-time" authentication step when the cert is
> accepted. There are no subsequent dynamic checks that the key or issuing
> device has not been compromised. A key continuity mechanism provides this
> kind of additional security.

Why do you think that's the case? If I lose my ZRTP phone, an attacker
can impersonate me just as well as if I lose the private key for
my cert.

-Ekr