Security Considerations update

1 files changed, 21 insertions, 6 deletions

diff --git a/doc/draft-ietf-codec-opus.xml b/doc/draft-ietf-codec-opus.xml
index f56bf5f1..b84f780d 100644
--- a/doc/draft-ietf-codec-opus.xml
+++ b/doc/draft-ietf-codec-opus.xml
@@ -5417,7 +5417,7 @@ calls in celt.h.
 <section anchor="security" title="Security Considerations">
 
 <t>
-The codec needs to take appropriate security considerations
+Implementations of the Opus codec need to take appropriate security considerations
 into account, as outlined in <xref target="DOS"/> and <xref target="SECGUIDE"/>.
 It is extremely important for the decoder to be robust against malicious
 payloads.
@@ -5434,17 +5434,32 @@ The reference implementation contains no known buffer overflow or cases where
  in CPU load.
 However, on certain CPU architectures where denormalized floating-point
  operations are much slower than normal floating-point operations, it is
- possible for some audio content (e.g., silence or near-silence) to cause such
+ possible for some audio content (e.g., silence or near-silence) to cause a certain
  an increase in CPU load.
 Denormals can be introduced by reordering operations in the compiler and depend
  on the target architecture, so it is difficult to guarantee that an implementation
  avoids them.
-For such architectures, it is RECOMMENDED that one add very small
- floating-point offsets to prevent significant numbers of denormalized
- operations or to configure the hardware to treat denormals as zero (DAZ).
-<!--TODO: Add small offsets to what? We should be explicit-->
+For architectures on which denormals are problematic, it is RECOMMENDED to 
+add very small floating-point offsets to the affected signals
+to prevent significant numbers of denormalized
+ operations. Alternatively, it is often possible to configure the hardware to treat
+ denormals as zero (DAZ).
 No such issue exists for the fixed-point reference implementation.
 </t>
+<t>The reference implementation was validated in the following conditions:
+<list style="numbers">
+<t>Sending the decoder valid packets generated by the reference encoder and 
+verifying that the decoder's final range coder state matches that of the encoder.</t>
+<t>Sending the decoder packets generated by the reference encoder, after random corruption.</t>
+<t>Sending the decoder random packets to the decoder.</t>
+<t>Altering the encoder to make random coding decisions (internal fuzzing), including
+mode switching and verifying that the range coder final states match.</t>
+</list>
+In all of the conditions above, both the encoder and the decoder were run inside
+the Valgrind memory debugger, which tracks reads and writes to invalid memory 
+regions, as well as use of uninitialized memory. There were no error reported
+on any of the tested conditions.
+</t>
 </section>