Subject: [Gen-art] Gen-ART LC review of draft-zimmerman-avt-zrtp-17

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 14 Apr 2010 18:32:53 -0400

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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

Good stuff!

-Pete

---

From: Jon Callas <[email-masked]>
Date: Wed, 14 Apr 2010 16:37:31 -0700

> It is not protected by the hash image technique described in Section 9.

It does not really.

Yes, that's a weasely thing to say, but let's suppose that I want to DoS you. I don't need error messages. If I can fling enough ICMP packets at you, you're going down. I can pick a bunch of ways to do this, too. Ping, SYNs, ACKs, RSTs, you name it. Heck, if I just start sending you ICMP host-not-reachable packets, you have problems.

At a higher level, I can fling enough badly formed packets from the media stream (either SRTP packets, out-of-sequence ZRTP state messages like hello packets, and so on) that you're going to have problems. I don't needs to send an error message.

But let's also look at the error message itself. Let's suppose that it is integrity-checked. What do you do with an error message that fails its integrity check? Some of these cases are amusingly absurd. Suppose you have a badly formed error message of type 0x10 (malformed packet). Is an erroneously formed malformed packet error therefore a success? Yes, I'm smiling as I say that. 

Even worse, though, some of the errors indicate crypto/data errors. Let me assume an evil router that flips some single bit (selected for maximum lulz) on many ZRTP messages. You try to talk to me and I get a bad packet because it's been damaged. I'll respond back to you (e.g.) that you have a bad HMAC, which gets itself damaged, because that maximizes the router's amusement. How do you handle a bad HMAC error that itself has a bad HMAC? The most entertaining thing is to conclude that because the HMAC was bad, that the error is wrong and in fact the packet you sent me had a good HMAC. It's also the most wrong. It is less wrong and less entertaining for you to send me an error message telling me that my HMAC is wrong in the packet I sent you telling you that you had an HMAC error. It's still wrong, and still entertaining. 

Unfortunately, the least entertaining way to handle this is to just accept it, and that's also the least wrong. Yes, it could be forged, but it could also be ignored; the only place in the document where we even suggest how to handle errors says that an implementation MAY drop the connection. An implementation is free to ignore errors, as undesirable as that it. The bottom line, though, is that authenticated error messages brings in its own baggage that is difficult, if not impossible to solve.

> name in the key derivation.  Maybe add some text here?

I don't think we *need* to, and while I can understand why we might *want* to, I don't know what to say that doesn't presuppose an implementation. The name that the application has is purely local to the implementation.  I am at a loss to think of something that would apply both to some stripped-down RTOS and so a full-blown OS with its own secure database. Obviously, the implementer has to treat the exported key with care because it's a key, but this is in fact the point in the document where we're telling the implementer that there's a separation between the protocol and something they have to do.

Do you have text you can suggest? If not, I'd say leave it as it is.

>   keyed hash over the encrypted part

Thank you. These are all great.

	Jon

---

From: Philip Zimmermann <[email-masked]>
Date: Wed, 14 Apr 2010 19:45:29 -0700

For the next draft, I just changed section 4.5.2 this way:

   ZRTP-enabled VoIP clients may need to support additional forms of
   communication, such as text chat, instant messaging, or file
   transfers.  These other forms of communication may need to be
   encrypted, and would benefit from leveraging the ZRTP key exchange
   used for the VoIP part of the call.  In that case, more key material
   MAY be derived and "exported" from the ZRTP protocol and provided as
   a shared secret to the VoIP client for these non-VoIP purposes.  The
   application can use this exported key in application-specific ways,
   outside the scope of the ZRTP protocol.

   The application may use this exported key to derive other subkeys for
   various non-ZRTP purposes, via a KDF using separate KDF string
   labels.  This key or its derived subkeys can be used for encryption,
   or used to authenticate other key exchanges carried out by the
   application, protected by ZRTP's MiTM defense umbrella.  The exported
   key and its descendants may be used for as long as needed by the
   application, maintained in a separate crypto context that may outlast
   the VoIP session.

I also fixed all the small nits you mentioned.

I agree with Jon regarding the ZRTP error message.

> Thank you. These are all great.

------------------------------------------------
Philip R Zimmermann    [email-masked]
(spelled with 2 n's)   http://philzimmermann.com
tel +1 831 425-7524    http://zfone.com

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 15 Apr 2010 11:48:29 -0400

The new text about derived exported keys looks good to me.

I agree there is no good way to authenticate the error messages,
especially when you haven't even agreed on keying material.  I
was just wondering if the possibility of an off-path DoS attack
using this vector should be mentioned.  It's technically ok to
just say MAY drop the connection, and allow the possibility to
ignore the error, I just wonder if it would be helpful to the
implementor to explicitly call out that he must use caution when 
making the decision about whether to accept or ignore.  Anyway, 
I'm fine if you want to leave the text as-is.

-Pete

Philip Zimmermann wrote:
>    used for the VoIP part of the call.  In that case, more key
>    material MAY be derived and "exported" from the ZRTP protocol and
>    provided as a shared secret to the VoIP client for these non-VoIP
>    purposes.  The application can use this exported key in
>    application-specific ways, outside the scope of the ZRTP protocol.
> 
>       ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated
>       hash length)
> 
>    The application may use this exported key to derive other subkeys
>    for various non-ZRTP purposes, via a KDF using separate KDF string
>    labels.  This key or its derived subkeys can be used for
>    encryption, or used to authenticate other key exchanges carried
>    out by the application, protected by ZRTP's MiTM defense umbrella.
>    The exported key and its descendants may be used for as long as
>    needed by the application, maintained in a separate crypto context
>    that may outlast the VoIP session.
> 
>> Yes, that's a weasely thing to say, but let's suppose that I want to
>> DoS you. I don't need error messages. If I can fling enough ICMP
>> packets at you, you're going down. I can pick a bunch of ways to do
>> this, too. Ping, SYNs, ACKs, RSTs, you name it. Heck, if I just
>> start sending you ICMP host-not-reachable packets, you have
>> problems.     
>> 
>> At a higher level, I can fling enough badly formed packets from the
>> media stream (either SRTP packets, out-of-sequence ZRTP state
>> messages like hello packets, and so on) that you're going to have
>> problems. I don't needs to send an error message.   
>> 
>> But let's also look at the error message itself. Let's suppose that
>> it is integrity-checked. What do you do with an error message that
>> fails its integrity check? Some of these cases are amusingly absurd.
>> Suppose you have a badly formed error message of type 0x10
>> (malformed packet). Is an erroneously formed malformed packet error
>> therefore a success? Yes, I'm smiling as I say that.     
>> 
>> Even worse, though, some of the errors indicate crypto/data errors.
>> Let me assume an evil router that flips some single bit (selected
>> for maximum lulz) on many ZRTP messages. You try to talk to me and I
>> get a bad packet because it's been damaged. I'll respond back to you
>> (e.g.) that you have a bad HMAC, which gets itself damaged, because
>> that maximizes the router's amusement. How do you handle a bad HMAC
>> error that itself has a bad HMAC? The most entertaining thing is to
>> conclude that because the HMAC was bad, that the error is wrong and
>> in fact the packet you sent me had a good HMAC. It's also the most
>> wrong. It is less wrong and less entertaining for you to send me an
>> error message telling me that my HMAC is wrong in the packet I sent
>> you telling you that you had an HMAC error. It's still wrong, and
>> still entertaining.            
>> 
>> Unfortunately, the least entertaining way to handle this is to just
>> accept it, and that's also the least wrong. Yes, it could be forged,
>> but it could also be ignored; the only place in the document where
>> we even suggest how to handle errors says that an implementation MAY
>> drop the connection. An implementation is free to ignore errors, as
>> undesirable as that it. The bottom line, though, is that
>> authenticated error messages brings in its own baggage that is
>> difficult, if not impossible to solve.       
>> 
>> 
>> 
>>> 
>>> 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? 
>> 
>> I don't think we *need* to, and while I can understand why we might
>> *want* to, I don't know what to say that doesn't presuppose an
>> implementation. The name that the application has is purely local to
>> the implementation.  I am at a loss to think of something that would
>> apply both to some stripped-down RTOS and so a full-blown OS with
>> its own secure database. Obviously, the implementer has to treat the
>> exported key with care because it's a key, but this is in fact the
>> point in the document where we're telling the implementer that
>> there's a separation between the protocol and something they have to
>> do.         
>>

---

From: Philip Zimmermann <[email-masked]>
Date: Sat, 24 Apr 2010 14:05:33 -0700

Peter, thanks for reviewing this draft.  It was a pleasure talking with you on the phone.  Your suggestions were helpful.

We addressed all the issues you raised in the next draft, draft 18.

Regards,
Phil