RE: [MMUSIC] Thinking about best-effort encryption

["Francois Audet" <audet@xxxxxxxxxx>]

You'll get very significant pushback from nework operators because of
increase
demand on proxies.

It also means that it's unsecure at answer time.

It's a valid mechanism, but I don't think it's  the best we can do.

I think IKR is right: we need to answer the very basic question about
do we "HAVE to use SAVP" to mean best effort.

The draft that Hadriel and I did assume "No". 
Flemming's draft assume "Yes". 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx] 
> Sent: Thursday, November 02, 2006 2:17 PM
> To: EKR
> Cc: ietf-rtpsec@xxxxxxxxxxxx; mmusic@xxxxxxxx
> Subject: Re: [MMUSIC] Thinking about best-effort encryption
> 
> While doing an update or reinvite may seem inelegant, I think 
> it makes reasonable sense for the best effort mode. It 
> certainly solves some problems regarding early media.
> 
> 	Paul
> 
> EKR wrote:
> > As people will recall, in the RTPSEC meeting in Montreal it became 
> > clear that we needed some way to support best-effort encryption. 
> > Loosely speaking, it seems to me that there are two major 
> ways to do this:
> > 
> > - Have nothing in the signalling and probe in the media plane
> >   as ZRTP does in bump in the wire mode.
> > - Have something in the offer that says "I will speak SRTP"
> >   but doesn't require it.
> > 
> > There have been a bunch of different suggestions about how 
> to do this 
> > (draft-andreasen-mmusic-sdp-capability-negotiation-01,
> > draft-kaplan-mmusic-best-effort-srtp-01, 
> draft-zimmermann-avt-zrtp-02, 
> > etc...). Regardless of which key management protocol we ultimately 
> > choose, we need to sort the fundamental architectural issue of:
> > 
> >    Does the signalling (SDP) have to reflect RTP/SAVP?
> > 
> > 
> > If the answer to this question is "Yes", then we either need to:
> > 
> > 1. Have some convenient way to offer multiple profiles (Flemming's
> >    draft surveys the space of options here).
> > 2. Do an UPDATE with RTP/SAVP for every secure connection. I get
> >    the impression people find this distasteful.
> > 
> > If the answer is "No", then you can simplify the 
> offer/answer exchange 
> > by having the signal that you will do security in an a-line, but at 
> > the cost of having the profile no longer reflect what's on the wire.
> > 
> > In either case, it seems like deciding this architectural issue is 
> > something we need to do before we spend a lot of time 
> discussing the 
> > details of mechanisms.
> > 
> > -Ekr
> > 
> > _______________________________________________
> > mmusic mailing list
> > mmusic@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/mmusic
>