system-updates-and-rollback: Clarify concerns about downgrade attacks

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

content/designs/system-updates-and-rollback.md

@@ -148,13 +148,22 @@ be customizable. For instance, some products may chose to only roll back the
 base OS and keep applications untouched, some other products may choose to roll
 applications back as well.
 
-Apertis recommends rollbacks to be allowed only after a system upgrade and before
-confirming that the new version works as expected. Enabling rollbacks in general
-could be a potential security issue, since a rollback could be used to install
-a previous release with vulnerabilities. By taking this approach it also
-simplifies how applications have to deal with base OS rollbacks, since
-applications should only upgrade their configuration accordingly when the new
-version is confirmed and there is no possible rollback.
+Rollbacks can be misused to perform
+[downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) where the
+attacker purposefully initiates a rollback to an older version to leverage
+vulnerabilities fixed in the currently deployed version.
+
+For this reason care need to be taken about the conditions on which a rollback
+is to be initiated. For instance, if the system is not explicitly in the
+process of performing an upgrade, rollback should never be initiated even in
+case of boot failure as those are likely due to external reasons and rolling
+back to a previous version would not produce any benefit. Relatedly, once
+a specific version has been booted successfully, the system should never
+roll back to earlier versions. This also simplifies how applications have to
+deal with base OS updates: since the version of the successfully booted
+deployment can only monotonically increase, user applications that get launched
+after the successful system boot has been confirmed will never have to deal
+with downgrades.
 
 ### Reset to clean state