[NXT] NXTInfrastructure committee

[opticalcarrier]

I am already covering all other aspects of finance and operations for the network of VPSs that I run.  These have been funded by neer.g and by 1 other donor, I think it was pouncer but not sure.  In any event, these 12 VPSs are funded till almost end of year and Im not requesting funding for them at this point.  I also run an additional 13 VPSs that are paid for by other members where I simply manage them for the users.

You may have seen development talk regarding lite clients and local signing of transactions so as to be able to run a client that does not maintain a blockchain - these clients simply query public VPSs for account status and they also sign transactions and feed the transactions to the public VPSs to be broadcast to the network and forged into a block by whoever the next forger is.

My proposal is to use HTTPS/SSL encryption on the VPSs to provide a measure of authentication between the users and the VPS used when local signing is implemented (very soon now).  This will provide a layer of authentication security from the VPS to the user.

Note that this HTTPS/SSL is not actually required.  But IMO it is worth pursuing, and not just for me, but for other VPS operators that can provide a very high level of uptime of their servers for the purpose of serving these lite clients.  Another benefit of real live SSL is that it will just "look good" for NXT to be able to brag that there is a network of SSL hosts out there serving the lite clients.

So like I said - not required as these lite clients *could* just use wellKnownPeers and send signed transactions to them, but IMO the better way to provide reliable service to lite clients is to have the lite client software devs use, instead of random wellKnownPeers, instead use a list of very well maintained, high-available nodes, like the nxtcrypto.org ones, along with others VPS operators who demonstrate competence, and for the added layer of security, use HTTPS/SSL on all of them as more solid proof that the folks running the NXT network know what they are doing.

However, I agree with BCNext on creating a system that is capable of operating without trust.  So if you cannot find multiple VPS networks to be preferred by lite clients to serve these lite clients, and mine is the only one, then that scenario would not be able to operate w/o trust and I (and everyone else) would prefer that my VPS network simply not be preferred by the lite clients at all, and in that case, IMO there would be no need for SSL.

So thats pretty much it, Ive laid out the pros/cons, you guys let me know.

[1715227633]

1715227633

[marcus03]

I've added my feedback on the paper to the issue at:

https://bitbucket.org/nxtinfrastructure/committee/issue/19/nxt-energy-efficiency-paper-secondleo

[marcus03]

@opticalcarrier: Thanks for posting the summary and, btw, thanks for managing these NRS nodes!

I have two questions:

1.) Your rationale is that you would like to offer SSL specifly for thin client that do the transaction signing themselves and that do no longer send the secret phrase over HTTP. As such, these clients can work with trustless (no trust needed) NRS nodes. What is the additional benefit of SSL in this case? What data in the communication between client and server needs SSL protection?

2.) Regarding the price for a one-year domain-wide SSL certificate, could you explain what the additional benefit of paying 468 € would be, compared to e.g. 122 € for the "Comodo PremiumSSL Wildcard" product (https://www.namecheap.com/security/ssl-certificates/comodo.aspx).

Thanks for your feedback!

[opticalcarrier]

1.) Your rationale is that you would like to offer SSL specifly for thin client that do the transaction signing themselves and that do no longer send the secret phrase over HTTP. As such, these clients can work with trustless (no trust needed) NRS nodes. What is the additional benefit of SSL in this case? What data in the communication between client and server needs SSL protection?

Like I said before, its not required, and can work in a trustless environment; like I said, the benefit is that NXT presents a more polished product to the worl to use if the lite clients:
1. Prefer a group of high availability servers
2. Those servers use SSL.

I guess I wasnt clear before in my email that this is mainly for the aesthetics of NXT's presentation of the lite client architecture, and that I mainly wanted the group to consider these 2 points and whether or not they thought it was worthwhile to pursue.

2.) Regarding the price for a one-year domain-wide SSL certificate, could you explain what the additional benefit of paying 468 € would be, compared to e.g. 122 € for the "Comodo PremiumSSL Wildcard" product (https://www.namecheap.com/security/ssl-certificates/comodo.aspx).

It is high because it is from a vendor that allows anonymity for certs AND the cert is a wildcard cert that will work with all hosts on a domain (remember we have 12 VPSs here).  At least I believe it allows anonymity, I am still waiting on verification from ITITCH.  If I cannot maintain anonymity or if they wont let me use some kind of alias then I wont pursue this at all.  But I am not opposed on a product from any much less expensive provider if they offer anonymity.

If I were offering a product to the world where my goal was to profit, then privacy wouldnt be a big deal.

[marcus03]

1.) Your rationale is that you would like to offer SSL specifly for thin client that do the transaction signing themselves and that do no longer send the secret phrase over HTTP. As such, these clients can work with trustless (no trust needed) NRS nodes. What is the additional benefit of SSL in this case? What data in the communication between client and server needs SSL protection?

Like I said before, its not required, and can work in a trustless environment; like I said, the benefit is that NXT presents a more polished product to the worl to use if the lite clients:
1. Prefer a group of high availability servers
2. Those servers use SSL.

Regarding point 1, having a group of high available servers with public access to the HTTP API is something we need and in my opinion something that should be funded if we find out, we don't have enough of these. There is however no connection that I see to have these groups of server use SSL and thus to your funding request.

I guess I wasnt clear before in my email that this is mainly for the aesthetics of NXT's presentation of the lite client architecture, and that I mainly wanted the group to consider these 2 points and whether or not they thought it was worthwhile to pursue.

Regarding point 2, I don't think it is wortwhile to have SSL enabled on NRS nodes at all and I think this is the reason why Jean-Luc dropped the default SSL configuration with one of the
last releases.

Technically, there is nothing that needs to be protected. The transaction data that is sent from clients to nodes, is the same data that is exchanged between nodes, which themselves do not uses SSL.
Or in other words, the beauty of the implementation lies in the fact that no trust is needed. It can't get any better. Putting SSL on top of it, for me just hides the beauty.

For the matter of perceived security ("aesthetics of NXT's presentation of the lite client architecture"), so basically doing SSL while it has no benefit from a security point of view, but having another buzzword for marketing, I think this might backfire on us. There might come up a discussion about nodes not using SSL and that there are safe SSL and unsafe non-SSL nodes and it will be hard to then explain that SSL was never needed in the first place.

2.) Regarding the price for a one-year domain-wide SSL certificate, could you explain what the additional benefit of paying 468 € would be, compared to e.g. 122 € for the "Comodo PremiumSSL Wildcard" product (https://www.namecheap.com/security/ssl-certificates/comodo.aspx).

It is high because it is from a vendor that allows anonymity for certs AND the cert is a wildcard cert that will work with all hosts on a domain (remember we have 12 VPSs here).  At least I believe it allows anonymity, I am still waiting on verification from ITITCH.  If I cannot maintain anonymity or if they wont let me use some kind of alias then I wont pursue this at all.  But I am not opposed on a product from any much less expensive provider if they offer anonymity.

Ah, ok. The product I referenced is a domain-wide SSL certificate, but likely does not offer anonymous registration.

Let's wait for others to give feedback on this subject.

[EvilDave]

Opticalcarrier/SSL certificates.

This discussion is slightly over my pay scale...guess I'd better get used to it.

After some research:
The SSL certification seems to really only give us an extra layer of cosmetic security on some nodes, but certainly not network-wide.This could maybe give rise to confusion as to whether a particular node is secure if it lacks SSL certification, when in fact the use of https adds no extra security for NXT transactions/balances.
J-L (and I assume CfB/BCNext) seem to have no use for https, so the SSL cert seems unnecessary.

I'd like to hear chanc3r and J-L's opinions on this, but I'm 80% against SSL certification right now.


Ferment/VPS

Just going to post a quick summary here of Ferments request:
***********************************************************************************************

Hello InfCom:

This is a heads up that sponsorship of the 102+ nxtbase nodes ends in a few weeks (3/31). I have created an issue for it here:
https://bitbucket.org/nxtinfrastructure/committee/issue/27/nxtbase-node-sponsorship-expires-3-31

I'm looking to the committee for ideas on how I should proceed given my involvement in this committee.  As we are just getting ramped up, I fear that 2 weeks will come and go pretty quick. I would hate to shut them down given that they account for a nontrivial amount stable network processing as well as providing 10 public API nodes in 10 geographically distinct locations.

I've included rickyjames on this message as I would appreciate his input on the ethics side of things.

I have no intention of using this committee for personal gain, but I am (as well as others) also some of the most capable people in the community for addressing the concerns of the committee (that's why we got voted in).

It's an interesting situation and I imagine affects the other committees as well.

Thoughts?

-Ferment

marcus03

How much do you need per node/VPS per months and for what is it spent? VPS hosting costs only or something else? Where do you host? Number of nodes=number of VPS?

   
ferment

marcus03 - Payment is for hosting, bandwidth, and personal time (gotta pay the bills). Servers are at Amazon, Rackspace, and Linode for both geographic and provider diversity. A node is run as a single virtual server.

   
marcus03

Thanks. Can you make a small list of planned expenses for a month for one node?

Hosting: ... NXT per month per NRS node Bandwidth: ... NXT per month per NRS node Personal time: ... NXT per month per NRS node Anything else...

 

ferment

1-2gb node with normal bandwidth charges is $25-35USD per month depending on location.

You can get much cheaper VPS options but you won't have the nice features like image cloning, international data centers, etc.

It's probably easier if I put together a proposal and submit it. I'll run the numbers and think how I could improve things and incorporate some of these brainstorming issues.

 
ChuckOne

ferment Sounds good for the start.

I would like to add that we definitely need long-term strategy for self-sustaining service providers. Any ideas on that?

   
ferment

ChuckOne One idea that I had was if you could integrate some kind of profitable PoW (distributed computing problem) then one could use the mostly idle nature of nodes to do other stuff.

For example, you could have a node do image conversions from one format to another and the node owner would get paid in NXT per unit of work completed. The work execution framework would run as an extension to NRS.

Building CPU mining pools on top of nxt nodes would be another example.

   


EvilDave wrote:

    I think it's an obvious decision, we need to have those nodes up and running, IMHO The only controversial part is whether Ferment gets a bounty for his own work on this. F; Have u recieved funding/bounty for your own workng time up til now? Do u want or expect payment for your worked hours on the VPSes?

ferment
Yes, I received sponsorships to pay for the nodes through the end of march. I've received bounties from BCNext/CFB as well for various contributions.

I'd happily run a few to support the community, but running 100+ across 10 data centers requires both time and financial commitment.

I think there are 3 approaches that could be applied to me or anyone else:

    Salary Bounty + Costs = Qualified individual gets paid on some kind of time frame to manage up to a certain amount of nodes. Committee pays hosting costs for these nodes directly. This is my least favorite, but it is what is implied when people ask about costs and time. It's highly centralized and requires trust.

    Bounties are paid per node per period of time directly to maintainer. How much time/expense is not the concern of the funding committee. The committee is only interested in the end result - a fast and resilient network. Nodes should receive bounties if they meet a clearly specified SLA regarding uptime, performance, updates, etc. This is the most common approach (sponsorships, peer explorer). In the absence of #3 below, I prefer this model, but it rewards investment in massive automation and the ability to grow on demand.

    Decentralized service providers are built on top of the nxt network. Nodes are rewarded through some kind of PoW that supports the business of the service provider. This is a long-term sustainable strategy until foraging become viable. Work processing code is distributed as "plugins" to NRS and run on nodes. Think Seti@home or CPU mining.

I'm sure there are other interesting models.

**************************************************************************************************

The above is from the INF-COM PMs and bitbucket convo, any one else want to weigh in, feel free....

[ferment]

The above is from the INF-COM PMs and bitbucket convo, any one else want to weigh in, feel free....

All issues posted by the committee are publicly viewable for those that want to see the initial brainstorming: https://bitbucket.org/nxtinfrastructure/committee/issues?status=new&status=open.

The nxtbase discussion is here: https://bitbucket.org/nxtinfrastructure/committee/issue/27/nxtbase-node-sponsorship-expires-3-31.

If anyone has ideas/suggestion, please post to this thread and we'll add them to the list of brainstorming issues.

-Ferment

[NxtMinnow]

opticalcarrier, thank you for carrying the torch on the SSL issue.

As Marcus03 pointed out, "Technically, there is nothing that needs to be protected. The transaction data that is sent from clients to nodes, is the same data that is exchanged between nodes, which themselves do not uses SSL.
Or in other words, the beauty of the implementation lies in the fact that no trust is needed. It can't get any better. Putting SSL on top of it, for me just hides the beauty."

However, in the case of an NXT client operating from behind the firewall of a crypto (freedom) unfriendly nationstate, the mere fact that transactions are transmitted "in the clear" provides easy detection ability that a cryptocurrency transaction occurred. I know that if the primary goal was profit at the core operation level of the Nxt network, SSL would not be considered. The socio-political definitions of what is acceptable to particular jurisdictions is likely to change often in the coming years, and I think that providing maximum security and the ability to maintain plausible deniability to end users is a strategic advantage to Nxt.

The transaction may be secure by design and will succeed, but what good is that if the originator of the transaction runs afoul of misguided local crypto regulations? I don't know if this helps or not: https://www.cacert.org/

[ferment]

However, in the case of an NXT client operating from behind the firewall of a crypto (freedom) unfriendly nationstate, the mere fact that transactions are transmitted "in the clear" provides easy detection ability that a cryptocurrency transaction occurred. I know that if the primary goal was profit at the core operation level of the Nxt network, SSL would not be considered. The socio-political definitions of what is acceptable to particular jurisdictions is likely to change often in the coming years, and I think that providing maximum security and the ability to maintain plausible deniability to end users is a strategic advantage to Nxt.

The transaction may be secure by design and will succeed, but what good is that if the originator of the transaction runs afoul of misguided local crypto regulations? I don't know if this helps or not: https://www.cacert.org/

If the usage is purely for encryption and not trust, why not use a self-signed cert? It would be nice if all public API nodes supported it, but yet all of them can't/won't buy wildcard SSL certs.

[Touque]

+1. Thanks!

[ferment]

Added a brainstorm issue for SSL on public api nodes:
https://bitbucket.org/nxtinfrastructure/committee/issue/30/public-api-nodes-could-support-ssl-for

I think this is an interesting topic separate from opticalcarrier's request for funding.

[NxtMinnow]

Hi Nxt community,

I am going to step out on a limb here a little. Let's say you have a safe in your house (Curve 25519 encryption algorithm) and do not have a lock on the front door to your house (HTTP). Even though you have a really awesome safe, you still don't really want everyone who wants to just wandering around your house.

All modern high security online facilities use a double lock security mechanism. The first lock is the HTTPS secured by a CA. The second lock(s) are the user passwords (names/passwords). Banks, schools, governments, etc. all use SSL connections. In the case of the need to remain anonymous, some nodes can be their own CA and issue their own certificates.

At the end of the day, when the rubber hits the road and the crypto becomes fiat; trusted (known) Nxt gateways that are in AML/KYC compliance will have HTTPS (SSL issued by a root CA). Would you enter your credit card number into a browser window requesting payment details that is NOT displaying the "Lock" icon? If your answer is YES to this question, then some serious study into network security is in order. All information transmitted over HTTP is the equivalent of talking on what used to be known as "the party line" to our grandparents. At least over HTTPS, only the NSA and GCHQ can peer into RSA; everyone else stays out of your house; for now.

Please be your own CA for now if that is what it takes for Nxt to "lock the front door". If anyone thinks I have my interpretation of network security all wrong, let me know. Otherwise, I think the competent and trusted network VPS operators need to take the steps required to make this a reality. Will the network run slower? Yes. Will there be more coding work required to the Nxt core? Yes. Will it cost money? Yes. Is it worth it? I think it is and so do at least a couple other Nxt community members.

Sincerely,
Brian Snyder

[jl777]

Hi Nxt community,

I am going to step out on a limb here a little. Let's say you have a safe in your house (Curve 25519 encryption algorithm) and do not have a lock on the front door to your house (HTTP). Even though you have a really awesome safe, you still don't really want everyone who wants to just wandering around your house.

All modern high security online facilities use a double lock security mechanism. The first lock is the HTTPS secured by a CA. The second lock(s) are the user passwords (names/passwords). Banks, schools, governments, etc. all use SSL connections. In the case of the need to remain anonymous, some nodes can be their own CA and issue their own certificates.

At the end of the day, when the rubber hits the road and the crypto becomes fiat; trusted (known) Nxt gateways that are in AML/KYC compliance will have HTTPS (SSL issued by a root CA). Would you enter your credit card number into a browser window requesting payment details that is NOT displaying the "Lock" icon? If your answer is YES to this question, then some serious study into network security is in order. All information transmitted over HTTP is the equivalent of talking on what used to be known as "the party line" to our grandparents. At least over HTTPS, only the NSA and GCHQ can peer into RSA; everyone else stays out of your house; for now.

Please be your own CA for now if that is what it takes for Nxt to "lock the front door". If anyone thinks I have my interpretation of network security all wrong, let me know. Otherwise, I think the competent and trusted network VPS operators need to take the steps required to make this a reality. Will the network run slower? Yes. Will there be more coding work required to the Nxt core? Yes. Will it cost money? Yes. Is it worth it? I think it is and so do at least a couple other Nxt community members.

Sincerely,
Brian Snyder

If infrastructure committee pays for half, I will authorized NXTcommunityfund to pay for the other half of the SSL cost. Maybe it is more of  marketing thing, but I think there is also technical merit to avoid plaintext transmissions, especially for NXTmixer and NXTcash usage.

James

P.S. If infrastructure committee doesnt want to pay anything, I will authorize NXTcommunityfund to pay for all of it. Just make sure that we are getting the right type of certificate. Ideally we can use this certificate for all the public nodes we are paying for?

[marcus03]

If infrastructure committee pays for half, I will authorized NXTcommunityfund to pay for the other half of the SSL cost. Maybe it is more of  marketing thing, but I think there is also technical merit to avoid plaintext transmissions, especially for NXTmixer and NXTcash usage.

Why? Do NXTmixer and NXTcash not work trustless?

[opticalcarrier]

Hi Nxt community,

I am going to step out on a limb here a little. Let's say you have a safe in your house (Curve 25519 encryption algorithm) and do not have a lock on the front door to your house (HTTP). Even though you have a really awesome safe, you still don't really want everyone who wants to just wandering around your house.

All modern high security online facilities use a double lock security mechanism. The first lock is the HTTPS secured by a CA. The second lock(s) are the user passwords (names/passwords). Banks, schools, governments, etc. all use SSL connections. In the case of the need to remain anonymous, some nodes can be their own CA and issue their own certificates.

At the end of the day, when the rubber hits the road and the crypto becomes fiat; trusted (known) Nxt gateways that are in AML/KYC compliance will have HTTPS (SSL issued by a root CA). Would you enter your credit card number into a browser window requesting payment details that is NOT displaying the "Lock" icon? If your answer is YES to this question, then some serious study into network security is in order. All information transmitted over HTTP is the equivalent of talking on what used to be known as "the party line" to our grandparents. At least over HTTPS, only the NSA and GCHQ can peer into RSA; everyone else stays out of your house; for now.

Please be your own CA for now if that is what it takes for Nxt to "lock the front door". If anyone thinks I have my interpretation of network security all wrong, let me know. Otherwise, I think the competent and trusted network VPS operators need to take the steps required to make this a reality. Will the network run slower? Yes. Will there be more coding work required to the Nxt core? Yes. Will it cost money? Yes. Is it worth it? I think it is and so do at least a couple other Nxt community members.

Sincerely,
Brian Snyder

If infrastructure committee pays for half, I will authorized NXTcommunityfund to pay for the other half of the SSL cost. Maybe it is more of  marketing thing, but I think there is also technical merit to avoid plaintext transmissions, especially for NXTmixer and NXTcash usage.

James

P.S. If infrastructure committee doesnt want to pay anything, I will authorize NXTcommunityfund to pay for all of it. Just make sure that we are getting the right type of certificate. Ideally we can use this certificate for all the public nodes we are paying for?

The only way to make 1 cert work for every single node is for every node to be a host on a single domain.  Given that then it would be possible for the domain administrator to revoke a cert, thus causing DoS, then it would be possible for a single entity (admin of whatever domain) to revoke everything.  so this is really a bad ideaa, and this is why in my proposal I suggested that different VPS operators use different SSL certs than what I do.

The free alternative (and not really that bad of a method either) is for use VPS operators to issue our own CA cert and sign our host nodes with that.  But then the client software devs for the lite clients will have to include all of these CA certs into their software package.  This should be a good solution, just has the extra step of organizing and including the certs into the software packages.  (This step isnt required if we use publicly trusted CA certs to sign our server certs, which is what I had originally asked funds for.

[opticalcarrier]

opticalcarrier, thank you for carrying the torch on the SSL issue.

As Marcus03 pointed out, "Technically, there is nothing that needs to be protected. The transaction data that is sent from clients to nodes, is the same data that is exchanged between nodes, which themselves do not uses SSL.
Or in other words, the beauty of the implementation lies in the fact that no trust is needed. It can't get any better. Putting SSL on top of it, for me just hides the beauty."

However, in the case of an NXT client operating from behind the firewall of a crypto (freedom) unfriendly nationstate, the mere fact that transactions are transmitted "in the clear" provides easy detection ability that a cryptocurrency transaction occurred. I know that if the primary goal was profit at the core operation level of the Nxt network, SSL would not be considered. The socio-political definitions of what is acceptable to particular jurisdictions is likely to change often in the coming years, and I think that providing maximum security and the ability to maintain plausible deniability to end users is a strategic advantage to Nxt.

The transaction may be secure by design and will succeed, but what good is that if the originator of the transaction runs afoul of misguided local crypto regulations? I don't know if this helps or not: https://www.cacert.org/

you make a really good point, and one that I had not even considered that I wish I had have included into my original proposal.  Much like BCNext's brainwallet provides plausible deniability, SSL would work alongside that for the same purpose.

And I do believe this will be temporary - maybe just for a year or 2 until SPs come along and provide the same functionality but on a basis where they are in the business to make $.  Then the SP will do their own cert.  But I am just running these VPSs to support NXT, not for profit, at least not anytime soon do I expect to be able to offer any kind of SP.

Another reason I want a domain wildcard cert is to be able to provide it to the wiki admin.  They REALLY NEED a valid SSL cert for their wiki, for login/editing purposes of the editors.  Consider that ideally, TOR is likely to be used by many people and if using tor, you REALLY NEED to be using SSL for pretty much everything you can - tor basically presents a MITM that could do attacks if you dont SSL your connection.

[NxtMinnow]

Thank you James for your consideration of this important security issue. There definitely is technical merit in using SSL to avoid plaintext transmissions within the Nxt network, particularly with certain Nxt applications.

Marcus03, You are correct that NXTmixer and NXTcash work trustless.  However, as I mentioned earlier the mere fact that a Nxt transaction succeeds does not equate to guaranteed security of network participants. SSL represents the middle road of network security. It is not wide open for anyone to inspect, record, analyze patterns like the plaintext (HTTP) transmissions method of communication is.

The danger lies in the patterns that can be inferred from the mere fact that data has been transmitted. Originating and destination IPs can be identified and if HTTP is used every transaction can be identified too.
Implementing SSL into the Nxt ecosystem provides an important margin of security for network participants.

If infrastructure committee pays for half, I will authorized NXTcommunityfund to pay for the other half of the SSL cost. Maybe it is more of  marketing thing, but I think there is also technical merit to avoid plaintext transmissions, especially for NXTmixer and NXTcash usage.

Why? Do NXTmixer and NXTcash not work trustless?

[jl777]

If infrastructure committee pays for half, I will authorized NXTcommunityfund to pay for the other half of the SSL cost. Maybe it is more of  marketing thing, but I think there is also technical merit to avoid plaintext transmissions, especially for NXTmixer and NXTcash usage.

Why? Do NXTmixer and NXTcash not work trustless?

Some parts are fully trustless, some parts require some trust at least at first. When everything is integrated into the NXTcore, then it can become fully trustless.

Regardless, it is much more anonymous to NOT transmit any data in plaintext. Why let anybody into the house with unlimited time to crack the safe??? Lock the door, pull the blinds. https is better than http

I have no expertise in what method makes sense technically, I just know that it is better to have https than to not have it, in some cases critically so

James

[jl777]

https://bitcointalk.org/index.php?topic=345619.msg5683336#msg5683336

jean-luc says SSL is required

[marcus03]

https://bitcointalk.org/index.php?topic=345619.msg5683336#msg5683336
jean-luc says SSL is required

jean-luc says it might be better to not use the prepareBytes API call, and implement the missing 50 lines of code in the client, so that you don't have to have SSL.

"if you need to implement this logic on the client side, you might as well construct the byte array yourself, and not trust the server to do it for you correctly"