make it easier to evaluate the impacts of changing security policies

[jmayclin]

Problem:

It is difficult for a customer to determine the safety of changing security policies. It is difficult for them to figure out which capabilities they might be removing without manual inspection of the security policies.

Solution:

s2n-tls should document this information.

One potential solution is to make a "compatibility matrix" of all the possible security policy transitions.

Note: I'm make up capabilities, the proposed examples may not have accurate text, and are for UI demonstration only.

	default	default_tls13	20230317
default		DANGER	DANGER
default_tls13	DANGER		BREAK
20230317	DANGER	SAFE

The left column is the old policy, and the top row is the new policy. The table can be read as follows.

Moving from 20230317 to default_tls13 is SAFE, because 20230317 is a subset of default_tls13

Moving from default to default_tls13 is full of DANGER, but their have no overlap in compatible versions.

Ideally this table would include links to the actual capability differences between policies, which would let customers know that moving from default_tls13 to 20230317 would break customers using SHA1 digests in their signatures.

I would vote for this information being hosted in a simple static site.