Attention is currently required from: MaxF, cron2, flichtenheld, syzzer. plaisthos has posted comments on this change. ( http://gerrit.openvpn.net/c/openvpn/+/796?usp=email )
Change subject: Trigger renegotiation of data key if getting close to the AEAD usage limit ...................................................................... Patch Set 13: (5 comments) File src/openvpn/ssl.c: http://gerrit.openvpn.net/c/openvpn/+/796/comment/c237d8e4_41a211f7 : PS10, Line 134: static int64_t : tls_get_limit_aead(const char *ciphername) : { : int64_t limit = cipher_get_aead_limits(ciphername); : : if (limit == 0) : { : return 0; : } : : /* set limit to 7/8 of the limit so the renogiation can succeed before : * we go over the limit */ : limit = limit * 7/8; : : msg(D_SHOW_KEYS, "Note: AEAD cipher %s will be limited to a sum of %" : PRIi64 " for block and packets before renegotiation", : ciphername, limit); : return limit; : } > This function could return uint Done File src/openvpn/ssl.c: http://gerrit.openvpn.net/c/openvpn/+/796/comment/9c45c755_8086e09c : PS12, Line 144: /* set limit to 7/8 of the limit so the renogiation can succeed before > renegotiation Done http://gerrit.openvpn.net/c/openvpn/+/796/comment/ee3d97c9_67c4d1c6 : PS12, Line 146: limit = limit * 7/8; > Consider adding overflow checks. […] I changed the order to /8 * 7 which does not have the overflow problem and I think if we now off by a few packets because of the lower precision that is not doing much in the grand scheme. http://gerrit.openvpn.net/c/openvpn/+/796/comment/2ddba798_2401cb2d : PS12, Line 149: PRIi64 " for block and packets before renegotiation", > This suggests a hard limit, but it's a soft limit we can (and typically will) > exceed. […] The hard limit of 2**32-1 is still there. The higher pid limit only comes with the epoch patches and those actually have this as as a hard limit. I think implementing a hard limit for this feature is not so important, so I changed the message to indicate that there will be a renegotiation. http://gerrit.openvpn.net/c/openvpn/+/796/comment/55c0c5e2_32a406f5 : PS12, Line 3027: || aead_usage_limit_reached(usage_limit, &key_ctx_bi->decrypt, > This is a safety precaution? The sending party is ultimately responsible for > not exceeding the limit […] My thinking was that this code will most certainly only be in use when only one side is aware of the limitation. Since if both sides are aware, then both sides will probably also switch to use epoch data channel instead, which only the sender checks. I will add a comment to indicate this as well. -- To view, visit http://gerrit.openvpn.net/c/openvpn/+/796?usp=email To unsubscribe, or for help writing mail filters, visit http://gerrit.openvpn.net/settings Gerrit-Project: openvpn Gerrit-Branch: master Gerrit-Change-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7 Gerrit-Change-Number: 796 Gerrit-PatchSet: 13 Gerrit-Owner: plaisthos <arne-open...@rfc2549.org> Gerrit-Reviewer: MaxF <m...@max-fillinger.net> Gerrit-Reviewer: flichtenheld <fr...@lichtenheld.com> Gerrit-Reviewer: syzzer <stef...@karger.me> Gerrit-CC: cron2 <g...@greenie.muc.de> Gerrit-CC: openvpn-devel <openvpn-devel@lists.sourceforge.net> Gerrit-Attention: syzzer <stef...@karger.me> Gerrit-Attention: cron2 <g...@greenie.muc.de> Gerrit-Attention: flichtenheld <fr...@lichtenheld.com> Gerrit-Attention: MaxF <m...@max-fillinger.net> Gerrit-Comment-Date: Thu, 12 Dec 2024 15:49:22 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: syzzer <stef...@karger.me> Comment-In-Reply-To: MaxF <m...@max-fillinger.net> Gerrit-MessageType: comment
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
