[nanomsg] Re: Security and the Big Picture
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 13 Mar 2014 23:31:29 -0700
The problem there is history. Specifically, crypto protocols that don't have
much of it are very hard to trust - since it's a combination of "experts
hammered on _this exact design_ and found no issues" (since even miniscule
changes to a secure protocol can ruin it, thus noise being "based on" NaCl
actually provides very little reassurance for me), and it having enough time
for that hammering to happen.
It's why despite NaCl having good results from those who have examined it,
it still sees relatively little deployment - it's just too new for many.
Noise is newer still.
There's also the issue of "helpful" middleboxes which make deploying new
protocols on the wider internet very difficult. Even just new revisions of
TLS run into issues with various things assuming they know more than they
really do.
Carter Schonwald wrote:
> 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: