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:prz(_at_)mit(_dot_)edu]
Sent: Saturday, April 24, 2010 5:11 PM
To: Black, David
Cc: ops-dir(_at_)ietf(_dot_)org;
alan(_dot_)b(_dot_)johnston(_at_)gmail(_dot_)com; jon(_at_)callas(_dot_)org;
ietf(_at_)ietf(_dot_)org; rjsparks(_at_)nostrum(_dot_)com;
gonzalo(_dot_)camarillo(_at_)ericsson(_dot_)com
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, <Black_David(_at_)emc(_dot_)com>
<Black_David(_at_)emc(_dot_)com> 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
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
------------------------------------------------
Philip R Zimmermann prz(_at_)mit(_dot_)edu
(spelled with 2 n's) http://philzimmermann.com
tel +1 831 425-7524 http://zfone.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf