diff --git a/draft-birkholz-cose-tsa-tst-header-parameter.md b/draft-birkholz-cose-tsa-tst-header-parameter.md
index ad14408..c4f2534 100644
--- a/draft-birkholz-cose-tsa-tst-header-parameter.md
+++ b/draft-birkholz-cose-tsa-tst-header-parameter.md
@@ -161,16 +161,18 @@ Please review the Security Considerations section in {{-TSA}}; these considerati
 
 Also review the Security Considerations section in {{-COSE}}; these considerations apply to this document as well, especially the need for implementations to protect private key material.
 
-In the "Timestamp, then COSE" (TTC) sequence of operation, the TSA is
-given an opaque identifier (a cryptographic hash value) for the
-payload.
-While this means that the content of the payload is not directly
-revealed, to prevent comparison with known payloads or disclosure of
-identical payloads being used over time, the payload would need to be
-armored, e.g., with a nonce that is shared with the recipient of the
-header parameter but not the TSA.
-Such a mechanism can be employed inside the ones described in this
-specification, but is out of scope for this document.
+The following scenario assumes an attacker can manipulate the clocks on the COSE signer and its relying parties, but not the TSA.
+It is also assumed that the TSA is a trusted third party, so the attacker cannot impersonate the TSA and create valid timestamp tokens.
+In such a setting, any tampering with the COSE signer's clock does not have an impact because, once the timestamp is obtained from the TSA, it becomes the only reliable source of time.
+However, in both CTT and TTC mode, a denial of service can occur if the attacker can adjust the relying party's clock so that the CMS validation fails.
+This could disrupt the timestamp validation.
+
+In CTT mode, an attacker could manipulate the unprotected header by removing or replacing the timestamp.
+To avoid that, the signed COSE object should be integrity protected during transit and at rest.
+
+In TTC mode, the TSA is given an opaque identifier (a cryptographic hash value) for the payload.
+While this means that the content of the payload is not directly revealed, to prevent comparison with known payloads or disclosure of identical payloads being used over time, the payload would need to be armored, e.g., with a nonce that is shared with the recipient of the header parameter but not the TSA.
+Such a mechanism can be employed inside the ones described in this specification, but is out of scope for this document.
 
 # IANA Considerations