RE: OpsDir review of draft-zimmermann-avt-zrtp-17

[<[e-mail]>]

Phil,

The draft is well written - it was a pleasure to review it.  The added
text on automated systems conveys the warning well (e.g., "worse than
useless and absolutely unsafe to rely on a robot voice"), thanks for
adding it.  On backup/restore, I would elaborate somewhat on this added
text at the end of Section 15.1:

   Unlike the long-lived non-updated key material used by SSH, the
   dynamically updated shared secrets of ZRTP may lose sync if
   traditional backup/restore mechanisms are used.  This is mitigated by
   ZRTP's built-in cache backup logic.  (Section 4.6.1)

As I understand Section 4.6.1, the mitigation is partial, because after
a backup, once two calls have been made to the same party, the backed-up
secrets for that party no longer work.  In the above text, I would
insert "partially" before "mitigated" and explain that if 2 or more
calls to the same party are made after the secrets for that party are
backed up, then restoring the secrets for that party does not do
anything useful because both rs1 and rs2 will have been changed
subsequent to that backup.  It might be worth mentioning that it's a
deliberate protocol design decision to avoid high-value generated
secrets like the long-lived non-updated key material used by SSH (see
benefits discussed in the last paragraph of Section 3.1.2), and this
restriction on secret backup/restore is a consequence.

Thanks,
--David

> -----Original Message-----
> From: Philip Zimmermann [mailto:[e-mail]]
> Sent: Saturday, April 24, 2010 5:11 PM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail];
> [e-mail]
> Subject: Re: OpsDir review of draft-zimmermann-avt-zrtp-17
> 
> David, thank you for reviewing our draft.  Your suggestions were
helpful.
> 
> It was a pleasure talking with you on the phone.  I'm glad we had a
chance to discuss the points you
> raised.
> 
> We addressed all the issues you raised in the next draft, draft 18.
> 
> Regards,
> Phil
> 
> 
> 
> On Mar 29, 2010, at 6:43 PM, <[e-mail]>
<[e-mail]> wrote:
> 
> > I have performed an Operations Directorate review of
> >  draft-zimmermann-avt-zrtp-17
> >
> > Operations directorate reviews are solicited primarily to help the
area directors improve their
> efficiency, particularly when preparing for IESG telechats, and
allowing them to focus on documents
> requiring their attention and spend less time on the trouble-free
ones.  Improving the documents is
> important, but clearly a secondary purpose.  A third purpose is to
broaden the OpsDir reviewers'
> exposure to work going on in other parts of the IETF.
> >
> > Reviews from OpsDir members do not in and of themselves cause the
IESG to raise issue with a
> document. The reviews may, however, convince individual IESG members
to raise concern over a
> particular document
> > requiring further discussion. The reviews, particularly those
conducted in last call and earlier,
> may also help the document editors improve their documents.
> >
> > --------------
> >
> > This draft specifies a proposed protocol for keying SRTP.  It is
being published as an Informational
> RFC because the IETF chose a different proposal
(draft-ietf-avt-dtls-srtp) to publish as Proposed
> Standard.  If this draft had been proposed for standards track
publication, I would have characterized
> the automated system concern and the inability to backup secrets as
open issues that merited
> discussion in the draft - both are tagged with [*].  As this draft
will be published as informational,
> a lower standard of review may apply, and I leave it to the authors'
judgment as to what changes
> should be made.
> >
> > The operational aspects of the protocol are reasonably good - the
protocol goes to a significant
> effort to avoid having to pre-provision and maintain authentication
material by using an ephemeral DH
> exchange that is run from scratch on the first call between a pair of
participants.  The protocol also
> adapts an SSH-like "leap of faith" model to protect subsequent
interactions among the same parties.
> By itself, an unauthenticated DH exchange can easily be subverted by a
man-in-the-middle (MiTM) attack
> - the protocol defends against this by generating an identification of
the protocol run (SAS) at each
> end that can then be compared by the participants reading the SAS to
each other.  A successful MiTM
> attack will cause different SAS identifiers to be generated at the two
call endpoints.
> >
> > [*] The draft asserts that it is very difficult for an MiTM attacker
to change the SAS on the fly in
> audio.  There is an obvious exception to this difficulty - if one of
the parties on the call is an
> automated system, its voice response reading the secret is likely to
have a predictable structure, and
> its vocalizations are likely to be easily recordable and/or otherwise
forgeable by an MiTM.  This
> should be noted in the security considerations section after the
paragraph on voice spoofing at the
> bottom of p.99, with a strong recommendation that credentials be
provisioned at the automated system
> sufficient to use either the 7.2 signature technique or 8.1.1
integrity protection technique, and that
> those techniques always be used with pre-recorded or synthesized
voice.
> >
> > If the first call between two parties does not include voice
confirmation of the SAS that instance
> of the protocol is MiTM-able.  The Introduction glosses over this by
using the phrases "reasonable
> authentication against a MiTM attack" and "key continuity properties
analogous to SSH".  While I
> believe both phrases are correct, the Introduction should also point
out that the first call with no
> prior shared key material is MiTM-able, as is the case for SSH, as not
every reader of this draft can
> be expected to be familiar with that aspect of SSH security.
> >
> > [*] Unlike SSH, ZRTP updates the shared secret used to block MiTM
attacks on every call.  This makes
> it impossible to backup and restore that secret because the backup
becomes invalid on next use of the
> secret.  If a phone has to be hard reset (not unheard-of), it loses
all of its secrets unless a backup
> is conducted immediately prior to the hard reset (not always possible
as the failure requiring a hard
> reset may block backup).  This should to be pointed out as a
counterpoint in the Security
> Considerations discussion of the requirements for protecting
long-lived non-updated shared secrets, as
> used by SSH.
> >
> > This ongoing shared secret update may increase the protocol's
practical vulnerability to MiTM
> attacks because the participants cannot distinguish presence of an
MiTM attacker from one party having
> lost its secret (or even the most recent update to the secret - a soft
reset of the phone at exactly
> the wrong moment may cause this).  If the parties assume that the most
common reason for setup failure
> is that a secret has been lost, an MiTM attacker inserts can mimic
that by inserting herself in a
> call, thereby causing both sides to believe that the secret has been
lost.  She then attacks the
> resulting initial run of the protocol - if voice confirmation of the
secret is not used on that run,
> the attack succeeds.  Because this attack can be run at the time of
the attacker's choosing, it is
> absolutely essential that the SAS's be confirmed by voice in this
situation.  This is well described
> in the body of the draft, with appropriate use of MUST, but the
following text in the Security
> Considerations section is too weak (IMHO), even though it uses the
word "must":
> >
> >   The user agent that discovers the cache mismatch must alert the
user
> >   that a cache mismatch has been detected, and that he must do a
verbal
> >   comparison of the SAS to distinguish if the mismatch is because of
a
> >   MiTM attack or because of the other party losing her cache.
> >
> > I would like to see a discussion of this attack added to punctuate a
direct warning that voice
> confirmation is essential in this situation.
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> 
> ------------------------------------------------
> Philip R Zimmermann    [e-mail]
> (spelled with 2 n's)   http://philzimmermann.com
> tel [phone]    http://zfone.com
> 
> 
> 
>