30 Oct
2013
30 Oct
'13
3 a.m.
On 29 Oct 2013, at 16:47, Alex Balashov <abalashov(a)evaristesys.com> wrote:
On 10/29/2013 08:38 AM, Charles Chance wrote:
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
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...