RE: Thinking about best-effort encryption

["Francois Audet" <audet@xxxxxxxxxx>]

I'm not sure what you mean by "a subset of encryption required", but it's not
a sufficient condition.

It absolutely needs to be backward compatible with edpoints that
only support RTP (and no SRTP). Plain Jane endpoints that don't do SAVP, 
grouping, or any of the new esoteric stuff we are strugling with. By backward
compatible, I mean a normal non-SRTP session should be the result.

Both Flemming proposal and Hardriel/François's proposal are backward compatible.

The port overloading stuff is not, and neighter are some of the media grouping
ideas.

If it's not backward compatible it is a non-starter because nobody will be 
stupid enough to deploy a feature that means the phone suddently fails to 
make calls. 

> -----Original Message-----
> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Michael 
> Richardson
> Sent: Sunday, November 05, 2006 10:28
> To: mmusic@xxxxxxxx; ietf-rtpsec@xxxxxxxxxxxx
> Cc: EKR
> Subject: Re: Thinking about best-effort encryption
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>>>> "EKR" == EKR  <ekr@xxxxxxxxxxxxxxxxxxxx> writes:
>     EKR> As people will recall, in the RTPSEC meeting in Montreal it
>     EKR> became clear that we needed some way to support best-effort
>     EKR> encryption. Loosely speaking, it seems to me that 
> there are two
>     EKR> major ways to do this: 
> 
>   That's fine, and I am all for this.
>   I think, though, that the best effort encryption needs to 
> be a subset of the "encryption required" situation.
> 
>     EKR> - Have nothing in the signalling and probe in the media plane
>     EKR> as ZRTP does in bump in the wire mode.
> 
>   That's fine, but then we can't ever make any decisions 
> about the call based upon whether or not it's secure.
> 
>     EKR> - Have something in the offer that says "I will speak SRTP"
>     EKR> but doesn't require it.
> 
>   I think you mean "I am willing to speak SRTP".
> 
>     EKR> In either case, it seems like deciding this 
> architectural issue is
>     EKR> something we need to do before we spend a lot of 
> time discussing
>     EKR> the details of mechanisms.
> 
>   I agree.
> 
> - -- 
> ]            Bear: "Me, I'm just the shape of a bear."        
>   |  firewalls  [
> ]   Michael Richardson,    Xelerance Corporation, Ottawa, ON  
>   |net architect[
> ] mcr@xxxxxxxxxxxxx      
> http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, 
> security guy"); [
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQEVAwUBRU4tP4CLcPvd0N1lAQJUBAf/ahvjezLqa1hadOcAJITev1VOmcGSRTKk
> e33xzYO8Lg6YUZxo6XLj1FaAAt15nlpfew5D8XZeLLXcNPQ/6KsEKdBxiCO748tj
> 6uCGHZRHPYGtg4GoA+c5XCHXnTCnCPHp4djtX9r3eK5FqLflY4vzPhIHtZyUeXIz
> nnY/3KcVzL7POvWWsYbmIJnReIWuzYDoouyoTPA3MxQXI3zIKtjlW+jxqVwuBHkV
> 81oxRR2b8Wr58whDMQgN6ynKoAZgOlFiMmaNGh9WeXrUMw1jo60doZvZX3CJunDF
> O5mM+BPQosocDb/xfBmu5zumtwW6hSfxjReyFa0Ikwxr7CneYh87GA==
> =miml
> -----END PGP SIGNATURE-----
> 
>