Updates to CCSS Standard from CCSS Q1 2021 meeting

[P3B]

The following changes were approved by the CCSS Steering Committee at the Q1 meeting.

Changes: -Add documentation requirement for policies and procedures -Update standard to state testing covers an effective period -Remove deterministic wallet requirement -Remove unique address per transaction requirement

[jsmith-dev]

-Remove unique address per transaction requirement

Are there meeting notes / expanding the rationale of this change.. first glance seems like a non-trivial change, so interested to learn what precipitated the change in thinking on this guideline.

[Abstrct]

-Remove unique address per transaction requirement

Are there meeting notes / expanding the rationale of this change.. first glance seems like a non-trivial change, so interested to learn what precipitated the change in thinking on this guideline.

@jsmith-dev Thanks for the inquiry!

The committee has been discussing this very control for quite a while, so the decision wasn't made lightly. I'm happy to share some of the background that led to the ultimate change confirmed in this PR.

First some background on the original purpose of the control. There were two reasons why unique addresses per transaction were believed to improve the security of an organizations overall cryptocurrency posture:

1. When signing a transaction, the corresponding public key for an address is exposed as part of the signature proof. The public key being exposed makes funds stored in other inputs controlled by the same address vulnerable to (hypothetical) cryptanalysis by quantum computers.
2. it is a common privacy conscious technique to always use new addresses for receiving and "change" to thwart tracing exercises.

Another important piece of background, the initial draft of the CCSS was originally released February 2015, several months before the launch of Ethereum's mainnet went live - a blockchain that uses account based addresses rather than the UTXO style we were all accustomed to.

So with that all in mind, now 6 years after that initial draft, what has led to the removal of this control?

That last point is certainly important, due to the way Ethereum handles addresses, it was basically impossible for any system that deals with Ethereum to be compliant with the CCSS. A basic (non-smart contract) transaction on Ethereum is unable to specify multiple recipients so even a simple scenario of sending ETH from one address to another would require one transaction for the initial send, and a second transaction to move change to a new address. This paradigm just doesn't make sense here.

Anecdotally, some of us had been assessing businesses who had wonderful mature controls in place, but since they also deal with Ethereum they either had to put some kludgy work-around in place to be compliant, or accept that they weren't able to meet the requirements of the standard.

It wasn't always Ethereum either. I personally run a project that re-uses Bitcoin, Litecoin, Dogecoin, and Defcoin addresses as an intentional design choice and to date had just accepted it wasn't compliant with the CCSS regardless of the other controls we have in place.

These difficulties across the industry were very likely the catalyst for the discussion on if this control was still appropriate, but we certainly didn't want to relax a control purely for the sake of making the standard easier to meet.

Looking back at the two reasons for the control initially, our discussion came to two important conclusions:

1. The concern over quantum-enabled cryptanalysis is mostly paranoia at this current time. It can also be argued that if these attacks become reality, the entire network (and other financial systems) are in such a state of disarray that the safety of any specific single address is almost a non-issue.
2. Based on the success of wallet/transaction tracing tools across the industry, used for compliance programs and investigations, we're not convinced fresh addresses actually add a substantial enough veil to justify the requirement. Additionally, there are some systems (consider Satoshi Dice) that more than justify the use of a vanity address as a core part of their business and it would be a shame if businesses saw this particular control as a reason to ignore the rest of the CCSS. ​

I hope this has helped to explain the reasoning for the change to this control. Of course, we always welcome input and suggestion from the community so please do speak up if you have additional concerns we may not have considered.

[mperklin]

The changes listed here match my memory of the meeting

[Abstrct]

I've also reviewed the changes in this PR and agree that they match the outcome of the committee discussions.

Formatting also looks correct for the static page generation.