[nanomsg] Re: Security and the Big Picture

  • From: Carter Schonwald <carter.schonwald@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Thu, 13 Mar 2014 17:25:53 -0400

not sure if this is relevant to the ongoing security discussion you guy's
are having, but a very solid crypto person in the haskell community pointed
me to  noise protocol

https://github.com/trevp/noise/wiki
associate example haskell implementation
https://github.com/thoughtpolice/hs-noise

noise seems to have a lot of good properties, though i'm not sure how well
it'd play with nanomsg :)
-Carter


On Wed, Mar 12, 2014 at 6:17 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> There have been a lot of talk about adding security to nanomsg in past
> few days.
>
> In this email I am not going to discuss any concrete proposals, rather
> it tries where the extension points are what pros/cons they have:
>
> Adding security at network level
> - --------------------------------
>
> 1. The security is added below the transports, e.g. IPSec, VPN.
> 2. No need to change nanomsg in any way.
>
> Adding security at transport layer
> - ----------------------------------
>
> 1. The security is added as a new transport protocol (e.g. "tls://")
> 2. The mechanism is transport-specific and won't work for other
> transport protocols.
> 3. It works only on hop-by-hop basis.
> 4. All the necessary params are passed to the transport either via
> connection string (e.g. "tcp://192.168.0.111:5555") or transport
> specific socket options (e.g. NN_TCP_NODELAY)
> 5. The transport does its best to keep the communication channels
> open, for expample by re-trying to open a channel after a failure.
> 6. It doesn't report any errors to the user (except via
> monitoring/management tools).
> 7. It doesn't report any specifics about peer identities to the user.
> 8. The problem is well understood and addressed by existing libraries.
>
> Adding security at scalability layer
> - ------------------------------------
>
> 1. The security is added to a specific SP protocol (e.g. REQ/REP)
> 2. It won't work for other SP protocols (e.g. PUB/SUB). In other
> words, if Drew is interested of implementing SP-level security for
> REQ/REP he can fully ignore PUB/SUB issues.
> 3. It works on end-to-end basis. The devices are not involved in any way.
> 4. All the necessary info can be passed via SP-protocol-specific
> socket options (e.g. NN_SUB_SUBSCRIBE).
> 5. It is completely agnostic of the underlying transport, i.e. is
> should work as well with TCP as with UDP etc.
> 5. The problem is not well understood and requires some original research.
>
> - From the implementation point of view, the good news is that in all
> cases the security is clearly decoupled from nanomsg core:
>
> 1. Security on network level -- nanomsg can be completely agnostic
> about it.
> 2. Security on transport layer -- the functionality is neatly
> contained in a transport. Transports have a well-defined interface and
> although they are compiled as part of nanomsg at the moment, they can
> be moved to separate shared libraries in the future.
> 3. Security on scalability layer -- in theory this can be built on top
> of nanomsg and possibly merged into it later on. Alternatively, it may
> turn out that it has to live directly inside existing SP protocols
> (rather than atop of them), in which case we have well-defined
> interfaces for building new SP protocols and we can even move them
> into independent shared libraries in the future.
>
> Martin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTIDQzAAoJENTpVjxCNN9Y900H/0vo058CNNoYxgASce2MJVdv
> 4QsMMId2yCaVZSfP3abyLJva8YL7GsTfTP0W38AI9BQP0VIc4e+v7g2NTBR9i+8f
> KfTRQrRWLqfTYNleo7qUMHPHwDfb2zn+X0X8+qIq312S+cqkT6/HXvKVLmpKnGnu
> RG2JiiF6GigIgwaC31jrSGiiaLNY/MaslGlNkCIhQlJbG8hqWoECC2vwujtMJUUZ
> YSIKzQKpp2jAWc1uE1f47pYMgJBR9Fv4+i5I0c6ZezGksZ+dg2aOPjEFK3DUSZHS
> cHI3bF9IrDxhoP/0VDnWy8bEVnjLFqrViN1HspFb0srC8aO9pPnywdGNIfQcnWw=
> =3oQT
> -----END PGP SIGNATURE-----
>
>

Other related posts: