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
