Document: draft-zimmermann-avt-zrtp-20
Reviewer: Pete McCann
Review Date: 17 May 2010
IESG Telechat date: 20 May 2010

Summary: Ready

Major issues: none

Minor issues:

I see that in draft-19, a change was made to stop using the
term "HMAC" and instead substitute "MAC".  However, in several
places, the term "keyed hash" seems to be used interchangeably
with the term "MAC".  For example, in Section 4.3.1:
   Both parties calculate a set of keyed hashes (MACs)  of shared
secrets
Is a MAC always a "keyed hash"?  I can imagine a scheme like
AES-GCM that provides an authentication tag without necessarily
using a hash function.  Anyway, this is a minor point.


Nits/editorial comments: none


======================================================================

Document: draft-zimmerman-avt-zrtp-17
Reviewer: Pete McCann
Review Date: 2010-04-14
IETF LC End Date: 2010-04-14
IESG Telechat date: unknown

Summary: Ready

Major issues: none

Minor issues:

Does the presence of the "Error" message open a denial-of-service
attack?
It is not protected by the hash image technique described in Section 9.

Section 4.5.2:
      ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash
      length)
Do we need to include an additional string parameter giving the name
of the application that will use the exported key?  That would provide
cryptographic separation when different applications each need their
own key.  Perhaps you would give ExportedKey to the operating system
and provide a new KDF that could be used by applications that have been
authenticated by name by the OS and which then include the application
name in the key derivation.  Maybe add some text here?

Nits/editorial comments:

Section 4.1.1:
   expected be
SHOULD BE:
   expected to be

Section 4.4.2.3:
   would then proceeds
SHOULD BE:
   would then proceed

Section 5.7:
   keyed hash over encrypted part
SHOULD BE:
   keyed hash over the encrypted part

Section 10:
   consider a audio
SHOULD BE:
   consider an audio