[nanomsg] Re: Security and the Big Picture
- From: Andrew Starks <andrew.starks@xxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 15 Mar 2014 14:01:11 -0500
On Friday, March 14, 2014, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
> 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/
> >>
> >> iQEcBAEBAgAGBQJTIDQzAAoJENTpV
Hello,
I'm Andrew and I lurk here often. [end intro :)]
I like the philosophy that the authors of Lua promote in their design[1]:
mechanism instead of policy.
Message passing and security are orthogonal, with layers below and above.
I'd like access and control over state parameters, also at the right
time, so that I can use the right tool chain to deal with issues like dos.
I imagine that history probably shows that a correct and simple message
passing system (with an implementation that reflects this) will have few
surprises and is one that can be made secure.
If there is a mechanism missing here or there, it's probably not a big one
that requires its own module, etc.
I also think this same approach could be taken for configuration.
Other related posts:
