Subject: Re: [AVT] I-D Action:draft-zimmermann-avt-zrtp-20.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 14 May 2010 10:23:13 +0100

On 11 May 2010, at 22:15, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : ZRTP: Media Path Key Agreement for Unicast Secure  
> RTP
> 	Author(s)       : P. Zimmermann, et al.
> 	Filename        : draft-zimmermann-avt-zrtp-20.txt
> 	Pages           : 111
> 	Date            : 2010-05-11
>
> This document defines ZRTP, a protocol for media path Diffie-Hellman
> exchange to agree on a session key and parameters for establishing
> unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP
> applications.  The ZRTP protocol is media path keying because it is
> multiplexed on the same port as RTP and does not require support in
> the signaling protocol.  ZRTP does not assume a Public Key
> Infrastructure (PKI) or require the complexity of certificates in end
> devices.  For the media session, ZRTP provides confidentiality,
> protection against man-in-the-middle (MiTM) attacks, and, in cases
> where the signaling protocol provides end-to-end integrity
> protection, authentication.  ZRTP can utilize a Session Description
> Protocol (SDP) attribute to provide discovery and authentication
> through the signaling channel.  To provide best effort SRTP, ZRTP
> utilizes normal RTP/AVP profiles.  ZRTP secures media sessions which
> include a voice media stream, and can also secure media sessions
> which do not include voice by using an optional digital signature.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-20.txt

This addresses some, but not all, of my comments on -17:

- “In terms of the RTP topologies defined in [RFC5117], ZRTP is  
designed for Point to Point topologies only” - if only Topo-Point-to- 
Point is supported, explicitly state that by shortcut name, otherwise  
also list the other topologies that are supported by shortcut name.

- “Other [RTP] profiles MAY also be used” - which ones? Need to be  
explicit, since not all conceivable RTP profiles would work with ZRTP.

- This version states that “SSRC collisions would be disruptive to  
ZRTP.  This may be avoided via the mechanisms in RFC 3550, Section 8.2  
[RFC3550]”. The mechanisms in section 8.2 of RFC 3550 explain how to  
resolve SSRC collisions, not how to avoid them, and say nothing about  
how to avoid disruption to ZRTP. Further clarification is needed - I’d  
guess that the right thing to do is to accept that SRRC collisions  
are  disruptive, and force a re-negotiation of the secure session. If  
so, the draft needs to state this explicitly.

- A ZRTP Error code of 0x91 “SSRC collision” is defined, but the text  
doesn’t mention how it’s used.

- The new discussion of timers for non-UDP transports in section 6 is  
much improved, but could still do with giving explicit recommendations  
for the lengthened timer intervals.

- The new text regarding the ZRTP header extension is better, but  
could still do with explicitly stating that not only does ZRTP not use  
the RFC 5285 mechanisms, it conflicts with them.

-- 
Colin Perkins
http://csperkins.org/