Re: [secdir] secdir review of draft-zimmermann-avt-zrtp-17

"Dan Harkins" <> Mon, 26 April 2010 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 550C43A69EE; Mon, 26 Apr 2010 12:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.596
X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K8h9gYL7CL-s; Mon, 26 Apr 2010 12:51:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 397653A69C2; Mon, 26 Apr 2010 12:51:03 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 75E521022404C; Mon, 26 Apr 2010 12:50:51 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Mon, 26 Apr 2010 12:50:51 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 26 Apr 2010 12:50:51 -0700
From: Dan Harkins <>
To: Philip Zimmermann <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [secdir] secdir review of draft-zimmermann-avt-zrtp-17
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Apr 2010 19:51:05 -0000

  Hi Phil,

  That makes sense. I guess that addresses the last of my comments
then (the previous ones were resolved over the phone). Thanks!


On Sat, April 24, 2010 2:22 pm, Philip Zimmermann wrote:
> Dan, thank you for reviewing our draft.  It's great to get comments from
> someone who understands hash functions so well.
> When we talked on the phone, I clarified the fact that we already use hash
> commits to address some of the concerns you raised below.
> I have adjusted our computations of srtps and ZRTPSess to use KDFs more
> effectively, because of our conversation.  This will be reflected in ZRTP
> draft 18.
> Your reference to Hugo's paper was most helpful.  Because of this, I read
> his paper, and called Lily Chen at NIST to discuss how NIST would use
> Hugo's ideas in the future.  She said NIST plans to update SP800-56A to
> address this.  As it stands, we are using the current version of SP800-56A
> to achieve strict NIST compliance to facilitate FIPS-140 validation
> testing.
> Regards,
> Phil
> On Mar 30, 2010, at 1:22 PM, Dan Harkins wrote:
>>  Hi,
>>  I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>>  This draft defines a Diffie-Hellman based key exchange to generate
>> a session key to use with SRTP. It prevents a man-in-the-middle attack
>> against the Diffie-Hellman key exchange without requiring traditional
>> authentication. It does not require use of a PKI.
>>  There are three things I think the ADs should take a look at: having
>> the protocol resist a small sub-group attack, use of the "auxsecret",
>> and
>> the hashing mishmash. All are described below.
>>  The MitM attack is thwarted by using a short authentication string
>> (SAS)
>> that is presented to users on each side of the ZRTP exchange to be read
>> and verbally compared.
>>  An immediate concern with such an approach is that it might enable a
>> small sub-group attack against the Diffie-Hellman exchange that would
>> be undetectable by verification of the SAS. An attacker could take an
>> element of small order, f, and create pvi' = pvi^f modp and
>> pvr' = pvr^f mod p and the shared secret, DHResult', would be confined
>> to
>> the small group. The SAS would verbally verify and the two parties would
>> continue unaware of the attack. But the DH shared secret is subsequently
>> used (indirectly) in a hash which fixes it and exposes it to the MitM,
>> which can run through the values in the small sub-group to determine
>> DHResult' and then attack the SRTP connection.
>>  The draft specifies support for a Diffie-Hellman domain parameter set
>> using a safe prime (from RFC 3526) which would prevent such an attack
>> but it seems that the protocol should be secure in and of itself and not
>> rely on external safeguards. I recommend sections and
>> define an additional processing step to ensure pvi and pvr are not in
>> a small sub-group. For a safe-prime this can be viewed as a "belt and
>> suspenders" approach, but I don't see why ZRTP couldn't be used in the
>> future with other domain parameter sets which may not be based on safe
>> primes and therefore such a check would be vital.
>>  The draft has a clever shared secret state matching algorithm to use
>> secrets from a cache of state associated with a peer. One of these is
>> called "auxsecret", as described in section 4.3.1:
>>   "the auxsecret shared secret may be manually provisioned in other
>>   application-specific ways that are out-of-band, such as computed from
>>   a hashed pass phrase by prior agreement between the two parties.  Or
>>   it may be a family key used by an institution that the two parties
>> both
>>   belong to."
>> If one does not have an "auxsecret" configured a random value is used in
>> its field during the ZRTP exchange. If one does have an "auxsecret"
>> though
>> it does not appear to change.
>>  Traffic analysis, therefore, would tell an attacker whether an
>> "auxsecret" is being used or not. If one is, an off-line dictionary
>> attack
>> might be possible if the "auxsecret" is being used per section 4.3.1 (if
>> it is a "family key used by an institution" then every member of the
>> institution would use the same "auxsecret" and that could also be easily
>> detected).
>>  I recommend that the "auxsecret" be updated in the cache in section
>> 4.6.1 so that it is different with a subsequent run of the protocol. If
>> that logistically isn't possible then perhaps hash rs1 or rs2 with it
>> in 4.3.1 to produce "auxsecretIDi" and "auxsecretIDr". Since there is a
>> matching algorithm for r1 and r2 then it might be necessary to have two
>> "auxsecretIDi" and two "auxsecretIDr", one hashed with r1 and one with
>> r2. The cost is a little extra space but the benefit seems worth it.
>>  There is a confusing mix of hashing, HMACing, and KDFing. In section
>> a secret value s0 is derived using the KDF technique from
>> SP800-56A, which is not of the keyed variety, it just uses a hash
>> function
>> in counter mode. But if a preshared key is used then section
>> derives s0 with an HMAC-based KDF based on SP800-108. This value, s0,
>> is then used to derive the SRTP session key, the SAS, and various
>> encryption and integrity protection keys using the HMAC-based, SP800-108
>> version of a KDF. When a session is terminated all keys are destroyed
>> except ZRTPSess which is replace by a hash of itself. But it was
>> originally derived by a keyed KDF. This seems unnecessarily complex and
>> would make this protocol very difficult to analyze.
>>  There has been much discussion on the CFRG list about how the output
>> of a hash function is too structured to use the key to an HMAC (see
>> Hugo Krawczyk's HKDF draft). Whether the SP800-56A hash-style KDF is
>> good or whether the SP800-108 keyed HMAC-style KDF is good is a debate
>> for another forum but I think this draft should choose one and stick to
>> it. Keys derived from a hash function should not be used as keys to
>> an HMAC and keys derived from an HMAC-based KDF should not be replaced
>> with a simple hash of themselves.
>>  Editorial nits:
>>    * sections and mention the "width of the DH prime".
>>      How about "bit-length of the DH prime" instead?
>>    * section mentions ECDH but then goes on to specify the
>>      finite field (MODP) version of the exchange. I suggest adding an
>>      example of ECDH in and
>>  regards,
>>  Dan.
> ------------------------------------------------
> Philip R Zimmermann
> (spelled with 2 n's)
> tel +1 831 425-7524