Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]

From: Dave Singer <[email-masked]>
Date: Wed, 1 Nov 2006 13:29:18 -0800

OK, I am somewhat behind in this fast-movign thread, and if these 
have already been disposed of, I apologize.

At 6:46  -0500 27/10/06, Alan Johnston wrote:
>On the use of RTCP, this is a possibility in the future.  Since the 
>ZRTP protocol is designed to be deployable in the real world, a 
>requirement is that it not require additional NAT bindings - this is 
>a major obstacle today to the deployment of RTCP.

But this is logically independent of your problem.  "RTP requires too 
many NAT bindings" is a different issue from "RTP could do with 
ZRTP".  They should be addressed separately, and in particular you 
should not distort the solution to the second because there isn't 
(yet) a solution to the first.

>Another requirement of ZRTP is that it not be dependent on the 
>signaling channel.  It can use the signaling channel as an 
>additional out-of-band discovery and authentication channel, but it 
>can not have any dependency.

That's a very odd requirement.  It almost (almost) sounds like I want 
to do something between consenting end-points but they can't use the 
normal means of establishing consent.  Why is this?
-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mark Baugher <[email-masked]>
Date: Wed, 1 Nov 2006 13:46:28 -0800

On Nov 1, 2006, at 1:29 PM, Dave Singer wrote:

>> On the use of RTCP, this is a possibility in the future.  Since  
>> the ZRTP protocol is designed to be deployable in the real world,  
>> a requirement is that it not require additional NAT bindings -  
>> this is a major obstacle today to the deployment of RTCP.
>
> But this is logically independent of your problem.  "RTP requires  
> too many NAT bindings" is a different issue from "RTP could do with  
>> additional out-of-band discovery and authentication channel, but  
>> it can not have any dependency.
>
> That's a very odd requirement.  It almost (almost) sounds like I  
> want to do something between consenting end-points but they can't  
> use the normal means of establishing consent.  Why is this?

Well, I think it's about worshipping at the alter of end-to-end  
encryption of the call data rather than end-to-end privacy of the  
call.  Or they're barking up the wrong tree.  Choose your metaphor.

My two cents, here.

Mark

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Nov 2006 17:24:06 -0500

Mark Baugher <[email-masked]> writes:
>>> signaling channel.  It can use the signaling channel as an  additional
>>> out-of-band discovery and authentication channel, but  it can not have
>>> any dependency.
>>
>> That's a very odd requirement.  It almost (almost) sounds like I  want to
>> do something between consenting end-points but they can't  use the normal
>> means of establishing consent.  Why is this?
>
>Well, I think it's about worshipping at the alter of end-to-end  encryption
>of the call data rather than end-to-end privacy of the  call.  Or they're
>barking up the wrong tree.  Choose your metaphor.

Two reasons I suspect:
1) Current ZRTP implementations are generally "bump in the wire"
   implementations, done outside of the actual UA/endpoint/application.
   This may mean (especially in the case of SIP-over-TLS or other
   authenticated/encrypted SIP channels, or non-SIP call setup) that the
   ZRTP module has no access to, or ability to modify, the call signalling.
   This is seen as an advantage since it allows ZRTP to be deployed
   immediately without direct support from the vendors to increase
   security, and this helps break the chicken-and-egg issue.
2) It's harder to block ZRTP or know it's being used if it's not signalled.
   Now, this is somewhat spurious since if a SIP proxy wants to block ZRTP,
   they can just route the media through a relay/router and filter ZRTP
   setup messages (of whatever form) at that point.  However, in many cases
   doing that to all calls would be an undue burden to the relay, and if
   you don't do it to all calls, then the person being attacked this way
   can notice.  For some networks where the blocking is done at an access
   or interconnet router (such as at a cable CMTS) there's no additional
   bandwidth cost, since all the packets flow through it anyways - it just
   has to know (from the SIP server) which ones are RTP flows.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Dave Singer <[email-masked]>
Date: Wed, 1 Nov 2006 14:35:58 -0800

>    has to know (from the SIP server) which ones are RTP flows.

Thanks, this helps.

Now, maybe I am being dense.  But your inability to find and 
intercept and re-write the original signalling channel indeed stops 
you from changing the bits that flow end-end, but you don't want to. 
As you say, the recipient of this ZRTP stream has to re-generate a 
stream that the actual end-point recognizes as conforming to the 
pre-existing description.  You want to signal between the ZRTP 'ends' 
only, and you can use whatever signalling you like for that.  It 
doesn't have to be in-band, in the data stream.  These two 'z-ends' 
DO know about each other and DO need to know what they are doing, no?
-- 
David Singer
Apple Computer/QuickTime

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Nov 2006 18:01:08 -0500

Dave Singer <[email-masked]> writes:
>Thanks, this helps.
>
>Now, maybe I am being dense.  But your inability to find and intercept and
>re-write the original signalling channel indeed stops you from changing the
>bits that flow end-end, but you don't want to. As you say, the recipient of
>this ZRTP stream has to re-generate a stream that the actual end-point
>recognizes as conforming to the pre-existing description.

I may be dense, but I'm not sure exactly what you mean by that.

>You want to signal between the ZRTP 'ends' only, and you can use whatever
>signalling you like for that.  It doesn't have to be in-band, in the data
>stream.  These two 'z-ends' DO know about each other and DO need to know
>what they are doing, no?

The end-to-end solution of ZRTP is to do discovery and negotiation in the
media path.  The arguments here are over how to do that.

They want (I believe) to use media path partly or largely (as mentioned)
because they don't trust the signalling path - either blocking things
inadvertently (bad implementation) or purposely (to block untappable
encryption).  Also, a media-path exchange will generally be faster than a
signalling-path exchange (less hops, avoid possibly-loaded server).

It always can be blocked or MITM'd, but ZRTP provides ways to detect a MITM
unless it's been there since the first call between two talkers, and even
then it can be detected if they read off the key hash verifier.

Key exchange can be done many ways; part of what defines "ZRTP" is that
it's media-path and so more work to block/MITM.  Also, it does lend itself
to external bump-in-the-wire solutions, which signalling ones don't.

Note that the reliance on signalling a payload type (a=rtpmap:99 ZRTP/8000)
for the rtp-payload-type solution I proposed does NOT provide ZRTP with
their bump-in-the-wire ability.  They _could_ modify existing RTCP packets,
but generating RTCP packets may be tricky since they have to have RR/SR,
and properly spoofing those outside of the UA may be tricky.  Modifying
existing RTCP packets means you may need 20 seconds or more to exchange
keys -- assuming the implementation sends RTCP at all (not all do), and
does so every ~5 seconds.

---

From: Mark Baugher <[email-masked]>
Date: Wed, 1 Nov 2006 15:12:15 -0800

On Nov 1, 2006, at 2:24 PM, Randell Jesup wrote:

>>>> additional
>>> want to
>> encryption

This is what I was referring to above.  If someone is trying to block  
my encrypted calls, then I want to know about it - not circumvent  
it.  That SIP proxy has a lot of information about the call already;  
information that could be harvested.  So you might as well secure  
this channel and use it for security purposes.

I don't see the problem of using the signaling channel as being a  
privacy problem because so much information is already exposed.  But  
I do see a problem of establishing keys in a signaling channel that  
does not do a three-way or five-way handshake for each connection.

Mark

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Nov 2006 18:12:15 -0800

> normal means of establishing consent.  Why is this?

One reason is summarized here:
  http://zfoneproject.com/faq.html#signaling

the other reason is that zPhone, which is an implementation of ZRTP,
is a shim between the VoIP application and its underlying IP stack.
When zPhone notices you're sending RTP data, zPhone sends ZRTP 
'hello' packets, hoping to encounter a ZRTP implementation on 
the remote peer.  If the remote peer also runs ZRTP, the ZRTP 
key negotiation will be performed and then both zPhone 
implementations will thereafter encrypt the RTP traffic 
(from the application) as SRTP, using the keys that were 
negotiated in ZRTP.

ZRTP (draft-zimmermann-avt-zrtp-02.txt) does include a mechanism
to signal "I can do ZRTP" in SDP, using the "a=zrtp" attribute.
I don't believe zPhone attempts to use this function, though.
Certainly, if one imagines the SIP signaling from the application
is already TLS encrypted or HTTP digest protected with 
Authentication-Info, zPhone couldn't modify the SDP.

-d