top posting, for clarity: Current: 'the term "anti-amplification limit" means three times the amount of data received from an unvalidated address.'
Suggest something like: 'the term "anti-amplification limit" means an endpoint limits the amount of data it sends to three times the amount of data received from an unvalidated address.' You are currently missing the whole concept of the end point not sending more than 3 times the data it receives. The suggestion above is merely an example. You will need to make it work for the current draft (endpoints vs senders, etc. etc.) Deb On Thu, Jul 3, 2025 at 8:38 AM Thomas Fossati <[email protected]> wrote: > Hi Deb, thank you for you review and comments. > > See inline. > > cheers, t > > On Wed, Jul 02, 2025 at 05:33:35AM +0100, Deb Cooley via Datatracker wrote: > >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: > >---------------------------------------------------------------------- > > Section 2, para 3: The definition of 'anti-amplification limit' is > > incomplete. Three times the amount of data received compared to what? > > There is nothing to compare it to. It's an absolute value which counts > all the valid DTLS bytes your peer sent you with a source address that > is not yet validated, multiplied by three. This is, I think, what we > alreday say. > > > 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] > > I must be missing something subtle, because I really can't see where the > confusion with the current definition comes from. > > > 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? > > The basic ingredients are already in Figure 2: it's a combination of > "Inspect" on the slow path and "Inject" on the fast path. > > > 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)] > > OK, thanks. > See https://github.com/tlswg/dtls-rrc/pull/97/commits/40d210f3 > > We added a reference to 4086 at Russ's suggestion. It is referenced > from TLS 1.3 A.1, so it's probably redundant. However, I don't think > it hurts keeping it in place. > > Thank you! >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
