)]}'
{"id":"openvpn~796","triplet_id":"openvpn~master~I057f007577f10c6ac917ee4620ee3d2559187dc7","project":"openvpn","branch":"master","topic":"epoch","attention_set":{},"removed_from_attention_set":{"1000003":{"account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2024-12-21 22:19:21.000000000","reason":"Change was submitted"},"1000035":{"account":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},"last_update":"2024-12-12 20:02:46.000000000","reason":"\u003cGERRIT_ACCOUNT_1000035\u003e replied on the change","reason_account":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."}},"1000002":{"account":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"last_update":"2024-12-21 15:36:46.000000000","reason":"\u003cGERRIT_ACCOUNT_1000002\u003e replied on the change","reason_account":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"}},"1000001":{"account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2024-12-12 17:03:03.000000000","reason":"\u003cGERRIT_ACCOUNT_1000001\u003e replied on the change","reason_account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}},"1000030":{"account":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"last_update":"2024-12-21 22:19:21.000000000","reason":"Change was submitted"}},"hashtags":[],"change_id":"I057f007577f10c6ac917ee4620ee3d2559187dc7","subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","status":"MERGED","created":"2024-11-11 01:59:03.000000000","updated":"2024-12-21 22:19:21.000000000","submitted":"2024-12-21 22:19:21.000000000","submitter":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"total_comment_count":61,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"796-epoch","meta_rev_id":"60cdace5e0fa2f3fd463c8fcd46c1d139e56ad01","_number":796,"virtual_id_number":796,"owner":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},{"value":0,"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"value":0,"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"value":0,"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"}],"values":{"-2":"This shall not be submitted","-1":"I would prefer this is not submitted as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"default_value":0}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."}],"CC":[{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2024-11-11 01:59:07.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"},"state":"CC"},{"updated":"2024-11-11 01:59:07.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"state":"REVIEWER"},{"updated":"2024-11-11 17:59:19.000000000","updated_by":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"CC"},{"updated":"2024-11-29 14:05:53.000000000","updated_by":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"reviewer":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"state":"REVIEWER"},{"updated":"2024-12-11 21:15:40.000000000","updated_by":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},"reviewer":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},"state":"REVIEWER"},{"updated":"2024-12-21 15:36:46.000000000","updated_by":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"REVIEWER"}],"messages":[{"id":"8638c4f787883e4e6eb0b66e6d3e3cb050a1c820","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-11 01:59:03.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"9abcd351be8dbd387c8fc59148980e10585d6d58","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-11 16:41:31.000000000","message":"Uploaded patch set 2: Patch Set 1 was rebased.","accounts_in_message":[],"_revision_number":2},{"id":"34957685f77983019a9c7e6395237c232ff303ba","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2024-11-11 17:59:19.000000000","message":"Patch Set 1:\n\n(3 comments)","accounts_in_message":[],"_revision_number":1},{"id":"3e9f28b076dd20dff167d9d15cc390ec4ee7f17f","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-14 13:45:07.000000000","message":"Uploaded patch set 3: New patch set was added with same tree, parent tree, and commit message as Patch Set 2.","accounts_in_message":[],"_revision_number":3},{"id":"bb986e4e6da26d1e0dcf971a6cb8372ed00777cf","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-14 13:47:10.000000000","message":"Patch Set 3:\n\n(2 comments)","accounts_in_message":[],"_revision_number":3},{"id":"afcf6814afa043c75c922e428fd55d5bd2a97fea","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-15 15:12:22.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"434da8e27169e0df0f5e4acaf673a23b2bb18cb5","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-22 16:29:15.000000000","message":"Uploaded patch set 5: New patch set was added with same tree, parent tree, and commit message as Patch Set 4.","accounts_in_message":[],"_revision_number":5},{"id":"259b2bfa655d60a490fc7d1cc20815a381c0bc70","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-23 21:02:24.000000000","message":"Uploaded patch set 6: New patch set was added with same tree, parent tree, and commit message as Patch Set 5.","accounts_in_message":[],"_revision_number":6},{"id":"150e6e5a29cda7db0f8eca901804b8db34ae787e","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-11-28 09:47:14.000000000","message":"Patch Set 6: Code-Review-1\n\n(8 comments)","accounts_in_message":[],"_revision_number":6},{"id":"0a652af407cf7d74dc11e4a8509557937939a359","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-11-28 10:03:54.000000000","message":"Patch Set 6: Code-Review-2\n\n(6 comments)","accounts_in_message":[],"_revision_number":6},{"id":"17908acca7979992dd9601c928335dea43e192ba","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-28 18:40:35.000000000","message":"Patch Set 6:\n\n(6 comments)","accounts_in_message":[],"_revision_number":6},{"id":"25d998b172b67d59bf2ddd4e64731d73dd88d2e9","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-28 18:54:57.000000000","message":"Uploaded patch set 7.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":7},{"id":"f575e36cf636e398490162ce6a48436f3e6b1d18","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-28 19:02:02.000000000","message":"Patch Set 7:\n\n(9 comments)","accounts_in_message":[],"_revision_number":7},{"id":"359453f81cc339baf4cd71b5d5df0aee3a5ee1e3","author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"date":"2024-11-29 14:05:53.000000000","message":"Patch Set 7: Code-Review-1\n\n(3 comments)","accounts_in_message":[],"_revision_number":7},{"id":"7e6e9a3653b8653e73844708fc6daedd711a2469","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-30 12:46:35.000000000","message":"Patch Set 7:\n\n(2 comments)","accounts_in_message":[],"_revision_number":7},{"id":"83b764d2b164e97d8a6519027ff68b49e41b4bdf","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-30 12:48:30.000000000","message":"Patch Set 7:\n\n(1 comment)","accounts_in_message":[],"_revision_number":7},{"id":"d4de21e884e517820d3aabc4a8db7ad51dd96810","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-30 13:38:17.000000000","message":"Uploaded patch set 8.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":8},{"id":"b44b64e88c8f469124eeaea448900bb42da67b88","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-01 13:53:49.000000000","message":"Uploaded patch set 9: New patch set was added with same tree, parent tree, and commit message as Patch Set 8.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"**changekind:NO_CHANGE** OR **changekind:TRIVIAL_REBASE** OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":9},{"id":"fcc05243106c36915d96c4ed93314e5664947c4b","author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"date":"2024-12-02 14:26:21.000000000","message":"Patch Set 9: Code-Review-1\n\n(1 comment)","accounts_in_message":[],"_revision_number":9},{"id":"84c96fef8b437ad355bb5e099cc7cdeaa78f290c","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-03 11:06:26.000000000","message":"Patch Set 9:\n\n(1 comment)","accounts_in_message":[],"_revision_number":9},{"id":"f6e4c90ea688e292e7297d06a0c9be98a869f979","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-03 11:06:34.000000000","message":"Uploaded patch set 10.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":10},{"id":"20543d92afbd4416d1dc6c55967ec0fd946d56db","author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"date":"2024-12-03 13:48:12.000000000","message":"Patch Set 10: Code-Review-1\n\n(4 comments)","accounts_in_message":[],"_revision_number":10},{"id":"bd22f1fddc466e778cd22b88b8f44841bdccad9b","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-03 14:07:34.000000000","message":"Uploaded patch set 11.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":11},{"id":"1a0864d0704f1d06ed6e22ab29acc1f9f3ac49d6","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-03 14:08:33.000000000","message":"Uploaded patch set 12.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":12},{"id":"cb52fa621e4ae6ae2f21d91200e016f02ddc2179","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-03 14:08:37.000000000","message":"Patch Set 10:\n\n(2 comments)","accounts_in_message":[],"_revision_number":10},{"id":"05b5a9d885a5d03e70028a4e30889007aea27df5","author":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},"date":"2024-12-11 21:15:40.000000000","message":"Patch Set 12: Code-Review-1\n\n(5 comments)","accounts_in_message":[],"_revision_number":12},{"id":"9352f21b748d6446d60f6538cf4cbc7ed2cc4565","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-12 14:12:58.000000000","message":"Uploaded patch set 13.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n\nOutdated Votes:\n* Code-Review-1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":13},{"id":"c1212fe01ba31fca5580feda0d30f59492302ef3","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-12 15:49:22.000000000","message":"Patch Set 13:\n\n(5 comments)","accounts_in_message":[],"_revision_number":13},{"id":"a2f24612c5f14711f0a6d8cec44d574d0b8e73dc","author":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"date":"2024-12-12 17:03:03.000000000","message":"Patch Set 13: -Code-Review","accounts_in_message":[],"_revision_number":13},{"id":"85ce9192c2649af6e02fdbe55f8d4ee290e76847","author":{"_account_id":1000035,"name":"syzzer","display_name":"Steffan Karger","email":"steffan@karger.me","username":"syzzer","status":"Commits and comments are my own views, not those of my employer."},"date":"2024-12-12 20:02:46.000000000","message":"Patch Set 13: Code-Review+1\n\n(2 comments)","accounts_in_message":[],"_revision_number":13},{"id":"77c00073d824fa434e520f6cb721771475111e7d","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-20 14:49:42.000000000","message":"Uploaded patch set 14: Patch Set 13 was rebased.\n\nCopied Votes:\n* Code-Review+1 (copy condition: \"changekind:NO_CHANGE OR **changekind:TRIVIAL_REBASE** OR is:MIN\")\n","accounts_in_message":[],"_revision_number":14},{"id":"a361778579d8bffcd991a848a8536eaf6ec9f677","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2024-12-21 15:36:46.000000000","message":"Patch Set 14: Code-Review+2\n\n(1 comment)","accounts_in_message":[],"_revision_number":14},{"id":"60cdace5e0fa2f3fd463c8fcd46c1d139e56ad01","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2024-12-21 22:19:21.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":15}],"current_revision_number":15,"current_revision":"fb691d2dcc63a29dafdf11ca33837c758e2b13b7","revisions":{"2e245bcbbe910be83c9841195b20a3c9c9267672":{"kind":"REWORK","_number":1,"created":"2024-11-11 01:59:03.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/1","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/1","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/1 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/1","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"13c1eaf60a75ce4b19265c18caced77dfe83f561","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 01:50:57.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"226ab82755687d6b3845fcf04cc9fe256e342533":{"kind":"TRIVIAL_REBASE","_number":2,"created":"2024-11-11 16:41:31.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/2","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/2","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/2 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/2","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 16:41:25.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"079b0d2f6c815303734ba84225f3be2f37c0d617":{"kind":"NO_CHANGE","_number":3,"created":"2024-11-14 13:45:07.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/3","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/3","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/3 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/3","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-14 13:44:53.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"29ff998560c8df70504762e3913256fb9b55e7c0":{"kind":"REWORK","_number":4,"created":"2024-11-15 15:12:22.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/4","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/4","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/4 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/4","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-15 15:12:05.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"004e22d9fe9e5661b44b573f5a00f9230ccf1cdc":{"kind":"NO_CHANGE","_number":5,"created":"2024-11-22 16:29:15.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/5","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/5","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/5 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/5","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-22 16:29:06.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"aa59708e7e302b28096fa77280b8a705ce1680a0":{"kind":"NO_CHANGE","_number":6,"created":"2024-11-23 21:02:24.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/6","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/6","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/6 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/6","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-23 21:01:56.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoiding needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effects that connection with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nmuch longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nChange-Id: Idccc93f303d29869ef4ed10b6bb56f37efedf623\n\nTesting instructions: The easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\nChange-Id: I0d2c763fd1dcdacdd8993731fc4979e258d1da4e\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"ba3927d1925381f075bc166880aa37464e420314":{"kind":"REWORK","_number":7,"created":"2024-11-28 18:54:57.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/7","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/7","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/7 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/7","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d52ea247d9dec5262a09f3891db83b79b2ca403e","subject":"Change --reneg-bytes and --reneg-packets to 64 bit counters"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-28 18:50:24.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"2c2dbc600e6d054eaaff02181b4621ea27a88758":{"kind":"REWORK","_number":8,"created":"2024-11-30 13:38:17.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/8","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/8","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/8 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/8","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb878882388bfe9dc49b116190c5c6ae8918322d","subject":"macOS: Assume that net/if_utun.h is always present"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-30 13:11:35.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"b5a0812e542f29e0ac20da38102d241be5a68ba4":{"kind":"NO_CHANGE","_number":9,"created":"2024-12-01 13:53:49.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/9","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/9","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/9 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/9","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/9 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb878882388bfe9dc49b116190c5c6ae8918322d","subject":"macOS: Assume that net/if_utun.h is always present"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-01 13:47:59.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"a297a37ee53ae1c0ed4899b4c0dd5b46002d9ca6":{"kind":"REWORK","_number":10,"created":"2024-12-03 11:06:34.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/10","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/10","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/10 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/10","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/10 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb878882388bfe9dc49b116190c5c6ae8918322d","subject":"macOS: Assume that net/if_utun.h is always present"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-03 11:06:17.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"65dd328bbbc184f191148094052b43f4e5595299":{"kind":"REWORK","_number":11,"created":"2024-12-03 14:07:34.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/11","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/11","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/11 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/11","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/11 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb878882388bfe9dc49b116190c5c6ae8918322d","subject":"macOS: Assume that net/if_utun.h is always present"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-03 14:07:15.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"2a7112358b3dbe141bdce844e2edc2e3f0168388":{"kind":"REWORK","_number":12,"created":"2024-12-03 14:08:33.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/12","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/12","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/12 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/12","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/12 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cb878882388bfe9dc49b116190c5c6ae8918322d","subject":"macOS: Assume that net/if_utun.h is always present"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-03 14:08:20.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"f62118bf57240d2062de70a25d3cb0f03c0c26a5":{"kind":"REWORK","_number":13,"created":"2024-12-12 14:12:58.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/13","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/13","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/13 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/13","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/13 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"387c2076af14a0f1ba97b6ca0175d81d1e8391a5","subject":"forward: Fix potential unaligned access in drop_if_recursive_routing"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-12 14:12:52.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"9c0286b6241851ea40790fa175a70c1ac5db5b28":{"kind":"TRIVIAL_REBASE","_number":14,"created":"2024-12-20 14:49:42.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/96/796/14","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/14","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/14 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/14","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/14 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"baa9192851006e2dbb90b410011e61ecf2e01870","subject":"Use XOR instead of concatenation for calculation of IV from implicit IV"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-09-30 11:24:15.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-20 14:37:21.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"fb691d2dcc63a29dafdf11ca33837c758e2b13b7":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":15,"created":"2024-12-21 22:19:21.000000000","uploader":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"ref":"refs/changes/96/796/15","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/96/796/15","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/15 \u0026\u0026 git checkout -b change-796 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/15 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/15 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/15 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/96/796/15","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/96/796/15 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"db46d4d38bec59435a76bb0968d530b9426c551e","subject":"dns: clone options via pointer instead of copy"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-21 15:37:30.000000000","tz":60},"committer":{"name":"Gert Doering","email":"gert@greenie.muc.de","date":"2024-12-21 18:23:25.000000000","tz":60},"subject":"Trigger renegotiation of data key if getting close to the AEAD usage limit","message":"Trigger renegotiation of data key if getting close to the AEAD usage limit\n\nThis implements the limitation of AEAD key usage[1] with a confidentiality\nmargin of 2^-57, the same as TLS 1.3.  In this implementation, unlike\nTLS 1.3 that counts the number of records, we count the actual number of\npackets and plaintext blocks. TLS 1.3 can reasonable assume that for\nlarge data transfers, full records are used and therefore the maximum\nrecord size of 2**14 (2*10 blocks) is used to calculate the number of\nrecords before a new key needs to be used.\n\nFor a VPN like OpenVPN, the same calculation would either require using a\npessimistic assumption of using a MTU size of 65k which limits us to\n2^24 packets, which equals only 24 GB with more common MTU/MSS of 1400\nor requiring a dynamic calculation which includes the actual MTU that\nwe allow to send. For 1500 the calculation yields 2*29.4 which is a\nquite significant higher number of packets (923 GB at 1400 MSS/MTU).\n\nTo avoid this dynamic calculation and also avoid needing to know the\nMSS/MTU size in the crypto layer, this implementation foregoes the\nsimplification of counting just packets but will count blocks and packets\ninstead and determines the limit from that.\n\nThis also has the side effect that connections with a lot of small packets\n(like TCP ACKs) mixed with large packets will be able to keep using the same\nkey much longer until requiring a renegotiation.\n\nThis patch will set the limit where to trigger the renegotiation at 7/8\nof the recommended maximum value.\n\n[1]  https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-08.html\n\nTesting instructions:\n\nThe easiest way to test if this patch works as\nintended is to manually change the return value of cipher_get_aead_limits\nto some silly low value like 2048. After a bit of VPN traffic, a soft\nreset should occur that indicates being over the\n\n    TLS: soft reset sec\u003d41/3600 bytes\u003d59720/-1 pkts\u003d78/0 aead_limit_send\u003d1883/1792 aead_limit_recv\u003d1937/1792\n\nHere the send limit is over the limit (1792 \u003d 2048 * 8/7).\n\nChange-Id: I057f007577f10c6ac917ee4620ee3d2559187dc7\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\nAcked-by: Gert Doering \u003cgert@greenie.muc.de\u003e\nMessage-Id: \u003c20241221153731.1755-1-gert@greenie.muc.de\u003e\nURL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg30144.html\nSigned-off-by: Gert Doering \u003cgert@greenie.muc.de\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}