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: > 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. > > 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. > > I also fixed all the small nits you mentioned. > > I agree with Jon regarding the ZRTP error message. > > > > On Apr 14, 2010, at 4:37 PM, Jon Callas wrote: > >>> 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. >> >> 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. >> >> >> >>> >>> 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. >> >> Do you have text you can suggest? If not, I'd say leave it as it is. >> >>> >>> 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! >> >> Thank you. These are all great. >> >> Jon > > ------------------------------------------------ > Philip R Zimmermann [email protected] > (spelled with 2 n's) http://philzimmermann.com > tel +1 831 425-7524 http://zfone.com _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
