Making some tweaks to the draft

5.0/en/0x53-V53-WebRTC.md

@@ -22,35 +22,41 @@ It is important to note that these security requirements **do not apply to devel
 
 ## V53.1 TURN Server
 
-TURN (Traversal Using Relays around NAT) servers play a crucial role in WebRTC applications by facilitating peer-to-peer connections in challenging network environments. However, they can also introduce security risks if not properly configured and secured. These requirements only apply to systems that host TURN servers as part of their WebRTC infrastructure.
+TURN (Traversal Using Relays around NAT) servers play a crucial role in WebRTC applications by facilitating peer-to-peer connections in challenging network environments. However, they can also introduce security risks if not properly configured and secured.
+
+These requirements only apply to systems that host TURN servers as part of their WebRTC infrastructure.
 
 | # | Description | L1 | L2 | L3 |
 | :---: | :--- | :---: | :---: | :---: |
-| **53.1.1** | [ADDED] Verify that the TURN service allows access only to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to IPv4 and IPv6 addresses. | ✓ | ✓ | ✓ |
-| **53.1.2** | [ADDED] Verify that the TURN service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. |  | ✓ | ✓ |
+| **53.1.1** | [ADDED] Verify that the TURN service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses. | ✓ | ✓ | ✓ |
+| **53.1.2** | [ADDED] Verify that the TURN service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server. | | ✓ | ✓ |
 
 ## V53.2 Media
 
 Media security is paramount in WebRTC applications, as it directly impacts the confidentiality, integrity and availability of audio and video communications. By addressing these security concerns, developers can safeguard the media streams in WebRTC applications, preventing eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality.
 
+These requirements only apply to systems that...
+
 | # | Description | L1 | L2 | L3 |
 | :---: | :--- | :---: | :---: | :---: |
 | **53.2.1** | [ADDED] Verify that the key for the DTLS certificate is private by ensuring it is not reused in existing products or open-source projects and confirming it is not distributed or leaked. | ✓ | ✓ | ✓ |
 | **53.2.2** | [ADDED] Configure the media server to use and support strong cipher suites for the DTLS exchange, ensuring that the selected cipher suites are considered strong and secure. | ✓ | ✓ | ✓ |
-| **53.2.3** | [ADDED] Verify that the media server is not susceptible to the _WebRTC DTLS ClientHello Race Condition_ vulnerability by checking if the media server is publicly known to be vulnerable or by performing the race condition test. |  | ✓ | ✓ |
+| **53.2.3** | [ADDED] Verify that the media server is not susceptible to the "WebRTC DTLS ClientHello Race Condition" vulnerability by checking if the media server is publicly known to be vulnerable or by performing the race condition test. | | ✓ | ✓ |
 | **53.2.4** | [ADDED] Verify that SRTP authentication is checked at the media server to prevent RTP injection attacks from causing DoS or audio/video media insertion on new or existing media streams. | ✓ | ✓ | ✓ |
-| **53.2.5** | [ADDED] Verify that the media server can handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. |  | ✓ | ✓ |
-| **53.2.6** | [ADDED] Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. |  | ✓ | ✓ |
-| **53.2.7** | [ADDED] Verify that the media server can handle malformed SRTP packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. |  | ✓ | ✓ |
+| **53.2.5** | [ADDED] Verify that the media server can handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. | | ✓ | ✓ |
+| **53.2.6** | [ADDED] Verify that any audio and/or video recording mechanisms associated with the media server are able to handle a flood of SRTP packets from legitimate users by implementing rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. | | ✓ | ✓ |
+| **53.2.7** | [ADDED] Verify that the media server can handle malformed SRTP packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. | | ✓ | ✓ |
 
 ## V53.3 Signalling
 
 Signalling is a critical component of WebRTC applications, responsible for coordinating communication sessions between peers. The security of the signalling process is essential to prevent unauthorized access, eavesdropping, and service disruptions.
 
+These requirements only apply to systems that...
+
 | # | Description | L1 | L2 | L3 |
 | :---: | :--- | :---: | :---: | :---: |
-| **53.3.1** | [ADDED] Verify that the signalling server can handle signalling message flood attacks by implementing rate limiting at the signalling level. |  | ✓ | ✓ |
-| **53.3.2** | [ADDED] Verify that the signalling server is able to handle malformed signalling messages by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. |  | ✓ | ✓ |
+| **53.3.1** | [ADDED] Verify that the signalling server can handle signalling message flood attacks by implementing rate limiting at the signalling level. | | ✓ | ✓ |
+| **53.3.2** | [ADDED] Verify that the signalling server is able to handle malformed signalling messages by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques. | | ✓ | ✓ |
 
 ## References