Description
Problem:
The security policy table is very difficult to read, and contains a lot of information that is not useful to customers.
Solution:
I think that customers generally assume that they should pick a security policy from the table. However, there are 30 policies to chose from, and if "default" doesn't fit their use case we offer little guidance to make that process easier.
reduce the number of entries in the table.
There exists a small number of policies (e.g. ~ 6) that support ~ 99% of use cases (guesstimates). The only policies in the main usage guide table should be these. These policies would include the default* policies, and then 2 or 3 others that have specific use-cases like
- "supporting legacy customers while trying to maintain security" which would be relatively permissive
- "supporting absolutely all customers, even the ones with bad security posture" which would support all (most?) the things, even the ones that we don't like.
remove unnecessary columns
ChaCha20-Boosted is only supported by a single policy, but takes up so much screen space. This does not belong in the table.
And no one should be using SSLv3 and that could also be safely removed.
We don't need to justify the removal of a column, rather we need to justify it's continued existence.
appendix with all policies
Another customer use case is "I found this policy in our codebase and I need to know what it does". For these customers, we should provide an appendix which is an exhaustive list of the ciphersuites supported by all of the security policies. It may be worth our time to automate the generation of this information.
Requirements / Acceptance Criteria:
- No more than 8 rows in the security policy table, and preferably 6 or fewer
- an appendix listing all security policies and their support