[asterisk-dev] SRTP implementation

[John Todd]

At 2:41 PM +0200 2007/4/24, Olle E Johansson wrote:
>>24 apr 2007 kl. 04.37 skrev John Todd:
>>At 8:22 PM +0200 2007/4/23, Olle E Johansson wrote:
>>>23 apr 2007 kl. 19.55 skrev Russell Bryant:
>>>
>>>>John Todd wrote:
>>>>>To morph this into a -dev thread: if this patch were to become 
>>>>>(again) useful and error-free, is there any objection or 
>>>>>usefulness in adding it to TRUNK?  Personally, I think there is, 
>>>>>if there is a method by which SRTP can be activated or 
>>>>>de-activated from within the dialplan based on prior shared 
>>>>>secrets.  However, I have heard others disagree and object that 
>>>>>without signalling-based secure key exchange, SRTP is not worth 
>>>>>the effort.  Opinions?
>>>>
>>>>I agree with you.  I think that is a reasonable approach.  I 
>>>>can't speak for the quality of the patch itself as I have not 
>>>>reviewed it.  But, if it works, I would guess that it would not 
>>>>be too bad to get it into trunk.
>>>
>>>Kevin and I earlier decided that we wanted to delay this until we 
>>>had a complete security solution, with signalling based secure key 
>>>exchange ;-)
>>>
>>>/O
>>
>>I'm uncertain if this delay is appropriate, given that this patch 
>>has been in process since October of 2005 and there has yet to be 
>>any other suitable solution.  While it may be the case that further 
>>work is being done (bravo!) to create a replacement for chan_sip, 
>>that does not negate the work that Mikael has done if his patch 
>>indeed does what is intended.  Certainly a good start towards 
>>encouraging encryption is to get one half of the encryption problem 
>>solved for the most popular protocol, no?   When the new SIP 
>>architecture is put in place at some point in the future, perhaps 
>>there will be an Asterisk-based audience who is already familiar 
>>with using basic encryption and who will applaud the additional 
>>functionality.
>>
>>And I also disagree that there is not secure key exchange.  Having 
>>shared secrets is secure (though it does not scale) and it seems 
>>presumptive to not include a feature because it possibly could be 
>>misconfigured to create an unsecure system.  If that methodology 
>>were the case, Asterisk would still be functioning as a Zap-only 
>>environment with a rather large backlog of patches waiting for 
>>final approval.   And while it does not scale without the automatic 
>>key sharing, there are many instances where that does not matter.  
>>As an analogy: I'm certain more than 90% of the world's routers use 
>>default and/or static routes, and that seems to suit their 
>>operators just fine.
>
>I did not say that I have this opinion now, but that was one of the 
>reasons then.
>
>The first issue, that kept it out of focus for a long time was the 
>total lack of test responses from third parties and the fact that the
>first patch did not have any hooks into chan_sip - Mikael later fixed that.
>
>/O

While you don't explicitly state it, it sounds like you're more 
infavor these days of this patch.  Would you object to addition of 
this patch if it meets relevant coding guidelines and works as 
intended, after testing by a few more people?

Would anyone on the list object to it's addition into TRUNK if it 
meets those criteria?

JT