Deb Cooley has entered the following ballot position for draft-ietf-tls-dtls-rrc-18: No Record
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Mike Ounsworth for their secdir review. Section 2, para 3: The definition of 'anti-amplification limit' is incomplete. Three times the amount of data received compared to what? In RFC 9000, the definition is as follows: "Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit." I think you need to add '...means limiting data sent to an unvalidated address to three times the amount of data received...'. [at this point the requirement in Section 6 makes more sense] Section 5, off-path attacker bullet: '...copies of the observed packets...', does this mean replay packets? I'm not sure what is more widely understood. Possibly add a 'copy' or 'replay' row to Figure 2? Section 8, para 2: Please reword the last two sentences. Perhaps something like 'To prevent this,...using a reliable source of entropy. See Appendix C.1 of RFC 8446 for guidance.' [Note RFC 4086 is pretty old, most O/S have reasonable RNGs (which is what Appendix C.1 states)] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
