On 4/24/2010 2:11 PM, Philip Zimmermann wrote: > 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. >>
ZRTP uses a variant of a key rotation practice we designed as a part of my "Blunt Tunneling" service which renegotiates a key session dynamically within the context of the service after the well known key exchange is used to open the connection. Todd >> 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 Sec ur > 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 >
<<attachment: tglassey.vcf>>
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
