Subject: Re: [AVT] Last Call: draft-zimmermann-avt-zrtp (ZRTP: Media Path Key Agreement for Secure RTP) to Informational RFC

From: Colin Perkins <[email-masked]>
Date: Tue, 13 Apr 2010 18:19:37 +0100

On 17 Mar 2010, at 22:26, The IESG wrote:
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'ZRTP: Media Path Key Agreement for Secure RTP '
>   <draft-zimmermann-avt-zrtp-17.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2010-04-14. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.

I've reviewed this draft, and have a number of comments. The main  
issue is the scope of the protocol: it claims to be "Media Path Key  
Agreement for Secure RTP", but may be better titled "Media Path Key  
Agreement for Unicast Voice Telephony Using Secure RTP". The majority  
of RTP sessions cannot be secured using ZRTP, but this draft is  
virtually silent on its limitations. Some details follow:

- RTP is explicitly a group communication protocol, that supports a  
wide range of topologies [RFC 5117], and a wide range of media types.  
ZRTP is defined for point-to-point audio calls or group audio  
conferences with a centralised conference bridge, and doesn't support  
the full range of RTP topologies or media formats. This is probably an  
acceptable limitation, but needs to be much more clearly documented  
than in the present draft.

- The draft claims it works with the RTP/AVP profile (although this is  
misspelt AVP/RTP in section 3). This is only one of several RTP  
profiles that can be used, but nothing is said about the other RTP  
profiles, such as RTP/AVPF. To avoid confusion, the draft should  
explicitly state which of the other RTP profiles are supported and  
which are not.

- Section 5 uses the SSRC to associate ZRTP messages with an RTP  
stream, but doesn't appear to consider the possibility of an SSRC  
collision [RFC 3550 section 8.2].

- RTP can run over non-UDP transports, such as TCP and DCCP. Section 6  
of the draft defines retransmission timers for ZRTP that are  
reasonable for RTP/UDP/IP sessions, but not for RTP/TCP/IP or RTP/DCCP/ 
IP sessions. The draft needs to discuss use of ZRTP over non-UDP  
transports.

- Section 7.3 discusses relaying ZRTP through a PBX. There appears to  
be an assumption that the PBX is configured to provide point to  
multipoint service as an RTCP-Terminating MCU (Topo-RTCP-terminating- 
MCU in the terminology of RFC 5117). None of the other topologies  
defined in RFC 5117 are considered.

- The draft does not specify how traffic RTCP is secured. This might  
be done using the key negotiated on the media path, or it might  
require a separate ZRTP negotiation using multistream mode, but the  
draft doesn't specify.

- SDES is a commonly used abbreviation in the RTP community for RTCP  
Source Description packets, yet this draft uses it for other purposes.  
To avoid confusion, please expand the acronym (e.g., in Section 8.2).

- The recommendations in Section 8.3 to avoid VBR traffic with secure  
calls are at odds with the recent discussion in the AVT working group  
(IETF 76).

- Section 10 assumes that the presence of an RTP mixer can be  
determined from the signalling. This assumption is false in general,  
although it's true for some SIP-initiated calls.

- The RTP header extension for ZRTP (Section 12) conflicts with the  
mechanism defined in RFC 5285. At minimum, this conflict should be  
documented, and it might make sense to update this draft to use the  
RFC 5285 mechanism.

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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 23 Apr 2010 12:15:48 -0500

Colin,

Thank you for your detailed review of the draft.  See my comments below.

- Alan -

On 4/13/10 12:19 PM, Colin Perkins wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> final comments on this action.  Please send substantive comments to the
> I've reviewed this draft, and have a number of comments. The main issue
> is the scope of the protocol: it claims to be "Media Path Key Agreement
> for Secure RTP", but may be better titled "Media Path Key Agreement for
> Unicast Voice Telephony Using Secure RTP". The majority of RTP sessions
> cannot be secured using ZRTP, but this draft is virtually silent on its
> limitations. 

The draft does point out that it is for securing unicast RTP only.  For
example, in Section 1:

"ZRTP is designed for unicast media sessions in which there is a voice
media stream."

Including unicast in the title does seem to be a reasonable thing to do
and we will do that.

However, scoping it to voice telephony is not accurate.  While the Short
Authentication String is the preferred security mechanism, the protocol
also works with digital signatures and can be authenticated using an
integrity protected signaling channel. Neither of these methods require
a voice channel.

Some details follow:
> 
> - RTP is explicitly a group communication protocol, that supports a wide
> range of topologies [RFC 5117], and a wide range of media types. ZRTP is
> defined for point-to-point audio calls or group audio conferences with a
> centralised conference bridge, and doesn't support the full range of RTP
> topologies or media formats. This is probably an acceptable limitation,
> but needs to be much more clearly documented than in the present draft.

We propose adding unicast to the title and having this as the first
sentence of the Abstract:

"  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."

> misspelt AVP/RTP in section 3). This is only one of several RTP profiles
> that can be used, but nothing is said about the other RTP profiles, such
> as RTP/AVPF. To avoid confusion, the draft should explicitly state which
> of the other RTP profiles are supported and which are not.

ZRTP uses the RTP/AVP profile in order to support best effort encryption
without any reliance on signaling protocol extensions or mechanisms.
However, there is no reason why it won't work with other RTP profiles.

We will add text indicating this.

> 
> - Section 5 uses the SSRC to associate ZRTP messages with an RTP stream,
> but doesn't appear to consider the possibility of an SSRC collision [RFC
> 3550 section 8.2].

Sure - we should mention that if a VoIP call is forked to two endpoints,
and media sessions are established with both, and they both choose the
same 32 bit SSRC, then ZRTP will not be able to distinguish between them.

> of the draft defines retransmission timers for ZRTP that are reasonable
> for RTP/UDP/IP sessions, but not for RTP/TCP/IP or RTP/DCCP/IP sessions.
> The draft needs to discuss use of ZRTP over non-UDP transports.

If the media is transported end-to-end using a reliable transport, then
clearly ZRTP retransmissions are not needed.  However, there can be
cases involving relays where ZRTP could be sent over a reliable
transport part of the way, and an unreliable transport the rest of the
way.  We will add text recommending that if reliable transport is used,
then the retransmit timers should be lengthened.

> 
> - Section 7.3 discusses relaying ZRTP through a PBX. There appears to be
> an assumption that the PBX is configured to provide point to multipoint
> service as an RTCP-Terminating MCU (Topo-RTCP-terminating-MCU in the
> terminology of RFC 5117). None of the other topologies defined in RFC
> 5117 are considered.

I couldn't find where you got this idea from.  A PBX is not going to act
as an RTCP-Terminating MCU.  It will most likely act as a B2B for both
the signaling and media, but it will still be 1:1.  We can clarify this.
 ZRTP does not apply to all the topologies of RFC 5117.

> 
> - The draft does not specify how traffic RTCP is secured. This might be
> done using the key negotiated on the media path, or it might require a
> separate ZRTP negotiation using multistream mode, but the draft doesn't
> specify.

ZRTP doesn't define a new way to secure either RTP or RTCP - it just
provides a key agreement for SRTP.  RFC 3711 defines how to secure RTCP
given a master secret.  We should probably just state this.

> To avoid confusion, please expand the acronym (e.g., in Section 8.2).

Right - we'll call it "SDP Security Descriptions (SDES)" in the draft,
to avoid confusion between AVT and security readers.

> calls are at odds with the recent discussion in the AVT working group

Is this discussion captured in draft-perkins-avt-srtp-vbr-audio?  We are
currently reading this draft.

> 
> - Section 10 assumes that the presence of an RTP mixer can be determined
> from the signalling. This assumption is false in general, although it's
> true for some SIP-initiated calls.

Right - in some cases being in a conference call can be deduced from the
signaling (using 'isfocus' in SIP for example) or in other cases, only
the human will know.  We will clarify the text.

> documented, and it might make sense to update this draft to use the RFC
> 5285 mechanism.
> 

We will add text referencing RFC 5285 and explaining the relation.
Basically, the ZRTP usage and deployment of RTP header extensions
predates this standard.  Also, this model of negotiating header
extensions in the signaling does not fit with ZRTP's signaling
indpendent design.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 28 Apr 2010 12:36:27 +0100

Alan,

Thanks for your response - some comments inline.
Colin

On 23 Apr 2010, at 18:15, Alan Johnston wrote:

>>> consider the following document:
>>>
>>> The IESG plans to make a decision in the next few weeks, and  
>>> solicits final comments on this action.  Please send substantive  
>>> comments to the [email-masked] mailing lists by 2010-04-14.  
>>> Exceptionally, comments may be sent to [email-masked] instead. In  
>>> either case, please retain the beginning of the Subject line to  
>>> allow automated sorting.
>>
>>
>> Agreement for Unicast Voice Telephony Using Secure RTP". The  
>> majority of RTP sessions cannot be secured using ZRTP, but this  
>> draft is virtually silent on its limitations.
>
> However, scoping it to voice telephony is not accurate.  While the  
> Short Authentication String is the preferred security mechanism, the  
> protocol also works with digital signatures and can be authenticated  
> using an integrity protected signaling channel. Neither of these  
> methods require a voice channel.
>
> Some details follow:
>>
>> wide range of topologies [RFC 5117], and a wide range of media  
>> types. ZRTP is defined for point-to-point audio calls or group  
>> audio conferences with a centralised conference bridge, and doesn't  
>> support the full range of RTP topologies or media formats. This is  
>> probably an acceptable limitation, but needs to be much more  
>> clearly documented than in the present draft.
>

That's fine, but I do think the draft should explicitly refer to RFC  
5117 and state which of the RTP topologies described therein are  
supported.

...
> Sure - we should mention that if a VoIP call is forked to two  
> endpoints, and media sessions are established with both, and they  
> both choose the same 32 bit SSRC, then ZRTP will not be able to  
> distinguish between them.

An SSRC collision is possible, if unlikely, for unicast sessions in  
the absence of forking. I believe the draft needs to explicitly  
address what should be done in the event of an SSRC collision  
(presumably you should re-negotiate the security, which should be  
acceptable since collisions are rare).

>> - RTP can run over non-UDP transports, such as TCP and DCCP.  
>> Section 6 of the draft defines retransmission timers for ZRTP that  
>> are reasonable for RTP/UDP/IP sessions, but not for RTP/TCP/IP or  
>> RTP/DCCP/IP sessions. The draft needs to discuss use of ZRTP over  
>> non-UDP transports.
>

It's not clear how such scenarios can be distinguished, but okay. Some  
guidance on the appropriate values for the lengthened timers would be  
helpful.

>> - Section 7.3 discusses relaying ZRTP through a PBX. There appears  
>> to be an assumption that the PBX is configured to provide point to  
>> multipoint service as an RTCP-Terminating MCU (Topo-RTCP- 
>> terminating-MCU in the terminology of RFC 5117). None of the other  
>> topologies defined in RFC 5117 are considered.
>
> I couldn't find where you got this idea from.  A PBX is not going to  
> act as an RTCP-Terminating MCU.  It will most likely act as a B2B  
> for both the signaling and media, but it will still be 1:1.  We can  
> clarify this. ZRTP does not apply to all the topologies of RFC 5117.

But, again, you need to be explicit about how the topologies you're  
describing relate to those of RFC 5117, and which of the RFC 5117  
topologies are supported.

> Is this discussion captured in draft-perkins-avt-srtp-vbr-audio?

Yes.

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