[sr-dev] DMQ security

[Olle E. Johansson]

On 29 Oct 2013, at 16:47, Alex Balashov <abalashov at evaristesys.com> wrote:

> On 10/29/2013 08:38 AM, Charles Chance wrote:
> 
>> I agree with Olle that the common "pass the buck" attitude is wrong,
>> although in this case I don't believe securing the messages should be
>> mandatory. Often the communication between servers will be over a
>> private/secure network and the user should be allowed to disable it if
>> they deem it an unnecessary overhead.
> 
> My personal opinion, mine only, is that transport security is most efficiently provided by transport/network-layer technologies, especially inside static networks.
> 
> HTTPS/TLS on the web makes sense because web browsing inherently entails ad hoc connections to unfamiliar servers.  That's the very nature of the web and of the browser.  The argument could be made that this is also the nature of SIP when it comes to peer-to-peer IP/IP calling, but de facto, the few places where SIP-TLS is used, it seems to be mostly used to encrypt signaling between fixed peers (aka "a SIP trunk").  Or at least, that's my impression--I haven't done a study.
> 
> Either way, does DMQ traffic look more like WWW traffic, or more like infrastructure traffic between a fixed number of endpoints within a static topology?  I would contend that it is the latter, and for this reason, it should be up to the network administrator to build a secure network, use encrypted tunnels if necessary, etc.
> 
> However, I've always been against overcomplicating things, which isn't how IETF/standards/evangelism/advocacy/consulting careers are made...

That's the right strategy. But on the other hand we see that since we don't deliver security by default, no one implements it and then they happily blame the software for being insecure...

I don't think adding security by default is "overcomplicating", but that may be a discussion we can continue over a beer sometime, Alex.

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2374 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131029/58e01d72/attachment.bin>