Re: [MMUSIC] Thinking about best-effort encryption

[Flemming Andreasen <fandreas@xxxxxxxxx>]

Francois Audet wrote:

> You'll get very significant pushback from nework operators because of
> increase
> demand on proxies.
>  
Right. Also, it smells like preconditions and we all know how popular 
they are.

> 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". 
>
>  
Not quite - only the answer contains the negotiated profile.

-- Flemming

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