[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: Michael Powell <mwpowellhtx@xxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 16 Jun 2014 11:27:07 -0500
Hello,
It is an interesting discussion, and while I am by no means a security
expert, I have had experience with messaging layers, especially the
same application code.
In my own words, the assertion whether "security should be part of
nanomsg" is an interesting one.
In my mind there are a couple of layers, transport (socket level) and
messaging (application level). Also in my mind, in a "perfect" world
(qualified term "perfect"), these are completely decoupled from one
another.
Transport level involving things like tunneling handlers, SSL, and
things of this nature; basically, as far as I know them to be, socket
level issues. I believe this has been eluded to.
However, the layer(s) which I believe most other participants are
chatting about is application level. To separate these concerns is
smart on the part of the messaging author(s), nanomsg or otherwise.
The suggestion is whether messaging depends on application level
security, encryption and so on. I'm not sure a well designed messaging
system completely decouples the issue. Not to say they aren't, because
I cannot say one way or the other. However, if I am working with
and/or designing a messaging system, encrypting a message needn't care
how to transport it. Similarly, transporting a message needn't care
whether it was encrypted.
Then if you want to adapt in said messaging layer(s), by all means,
adapt away: needn't worry whether nanomsg was your transport, or
whether it was zeromq (since it was mentioned), or some other variety.
Of course, this isn't always practical, as has been mentioned,
depending how much control you have over participants in the network.
Anyhow, that's my take on it.
Regards,
Michael Powell
On Mon, Jun 16, 2014 at 11:07 AM, Achille Roussel
<achille.roussel@xxxxxxxxx> wrote:
> If I may give my opinion on the subject, saying nanomsg is not going to
> support security mechanisms because it's intended to be used inside private
> networks only is equivalent to expecting people not to use the lib at all.
> Maybe your requirements make it that you only have nodes in a single data
> center but companies have multi-data centers architectures and in nowadays
> world you can't trust any external link anymore not to be listened even if
> you're not going to the public internet explicitly.
> On top of that, more and more of our communications are wireless nowadays,
> we're using mobile devices and soon others like flying drones and
> communications on these channels will require some sort of security schema to
> protect communications.
> I think it's a matter of deciding whether nanomsg is designed to solved 5% or
> 95% of problems we face when we need to do message oriented networking
> (numbers are made up but you get the idea).
> That being said, the nanomsg design does make it more tricky in some cases to
> integrate existing security solutions, but nanomsg isn't perfect and we can
> work on trade offs to put it in a better place. If your apps require a strong
> security level you're probably willing to give away some features of the
> protocols you're using... There will always be cases where nanomsg was the
> wrong tool and it can't solve every world's issues, but it can be improved to
> help solving most of them.
>
> Achille Roussel
> +1 415 490 6339
>
>> On Jun 16, 2014, at 5:19 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> On 16/06/14 12:59, Drew Crawford wrote:
>>>
>>> There are certainly applications that can fit nicely in these
>>> requirements. But I think they are primarily, if not entirely,
>>> enterprise-style messaging applications. So this reinforces what I
>>> said earlier, that this trajectory leads to being a great
>>> messaging framework, and not an internet communications library.
>>
>> Well, yes.
>>
>> The good news is that no other library is doing better in this respect.
>>
>> Martin
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTnuDJAAoJENTpVjxCNN9YeWgH/RfSXe0N5/3DQtiIYWCl1lpE
>> 9IZewVsZ9TU92itJo+dGgIy8joJ3l4NWbLQAJl2dI5H2gJwsXTH8z9VET/F0nwvX
>> hC9OInpe6Nl/dRjFe8UNaUtbJoNAoMObaF1D+ric+uMUkaGMJprqCOwZcRcxWZ4O
>> 5FFLJlQ2v6Yqth9FGEodpIrtTrZLxN18w3MWIEAW8qfrekWbTKl0esK7ppRJXU+N
>> 979b7K4dZBIdZ4zavNozHPeN45lzo5GE+1Km5eNaumuw7XvDQciC9s5QI6jKsTLt
>> PVNaCsZvoZsQ03PLibz6NSNBTlkejW8RmpW8BaxoGR+d6qdtIEg5ieiBmBkIitY=
>> =otwm
>> -----END PGP SIGNATURE-----
>>
>
Other related posts:
