ietf
[Top] [All Lists]

Fwd: I-D Action:draft-zimmermann-avt-zrtp-20.txt

2010-06-03 10:53:55
See my comments below regarding SSRC collisions.


Begin forwarded message:

-------- Original Message --------
Subject: Re: [AVT] I-D Action:draft-zimmermann-avt-zrtp-20.txt
Date: Fri, 14 May 2010 10:23:13 +0100
From: Colin Perkins <csp(_at_)csperkins(_dot_)org>
To: IETF Discussion Mailing List <ietf(_at_)ietf(_dot_)org>
CC: IETF AVT WG <avt(_at_)ietf(_dot_)org>

On 11 May 2010, at 22:15, Internet-Drafts(_at_)ietf(_dot_)org 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.

See section 4.1, which does specify what to do if there is an SSRC collision.


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

Section 4.1 does mention how it is 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/



_______________________________________________
Audio/Video Transport Working Group
avt(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/avt

------------------------------------------------
Philip R Zimmermann    prz(_at_)mit(_dot_)edu
(spelled with 2 n's)   http://philzimmermann.com
tel +1 831 425-7524    http://zfone.com




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>