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_da...@emc.com> <black_da...@emc.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 Secur ity 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_da...@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- ------------------------------------------------ Philip R Zimmermann p...@mit.edu (spelled with 2 n's) http://philzimmermann.com tel +1 831 425-7524 http://zfone.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
