)]}'
{"id":"openvpn~806","triplet_id":"openvpn~master~I00751c42cb04e30205ba8e6584530831e0d143c5","project":"openvpn","branch":"master","full_branch":"refs/heads/master","topic":"epoch","attention_set":{},"removed_from_attention_set":{"1000030":{"account":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"last_update":"2025-02-12 16:11:24.000000000","reason":"\u003cGERRIT_ACCOUNT_1000030\u003e replied on the change","reason_account":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"}},"1000003":{"account":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2025-02-12 18:02:57.000000000","reason":"Change was submitted"},"1000002":{"account":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"last_update":"2025-02-09 15:27:21.000000000","reason":"\u003cGERRIT_ACCOUNT_1000002\u003e replied on the change","reason_account":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"}},"1000001":{"account":{"_account_id":1000001,"name":"Frank Lichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2025-02-12 18:02:57.000000000","reason":"Change was submitted"}},"hashtags":[],"change_id":"I00751c42cb04e30205ba8e6584530831e0d143c5","subject":"Implement epoch key data format","status":"MERGED","created":"2024-11-11 01:59:03.000000000","updated":"2025-02-12 18:02:57.000000000","submitted":"2025-02-12 18:02:57.000000000","submitter":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"total_comment_count":19,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"806-epoch","meta_rev_id":"6741fff70bcd468f4eefe26d3ac5dddcdb2f3431","_number":806,"virtual_id_number":806,"owner":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},{"value":0,"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"}],"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"},"description":"","default_value":0}},"removable_reviewers":[{"_account_id":1000001,"name":"Frank Lichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"Frank Lichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"}],"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:10.000000000","updated_by":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"real_updated_by":{"_account_id":1000003,"name":"Arne Schwabe","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:10.000000000","updated_by":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"real_updated_by":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000001,"name":"Frank Lichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"state":"REVIEWER"},{"updated":"2025-01-10 08:08:59.000000000","updated_by":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"real_updated_by":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"CC"},{"updated":"2025-02-03 15:40:48.000000000","updated_by":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"real_updated_by":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"REVIEWER"},{"updated":"2025-02-05 17:01:22.000000000","updated_by":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"real_updated_by":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"reviewer":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"state":"CC"},{"updated":"2025-02-12 16:11:24.000000000","updated_by":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"real_updated_by":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"reviewer":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"state":"REVIEWER"}],"messages":[{"id":"8551fcae84a19f2ca58ecda282dfd66423f93f52","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","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":"3d86b0ecfcc752e89a20b549ec9272b849d2ef9e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-11 16:41:31.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"49b62b7bbf94dac1881405212621c8cb5b01cc13","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-14 13:45:07.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"0cf90263269d1d9b242f7778125674c8899bfdc5","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","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":"f5e6660ef6c861ed704759c2f63bc875e71e38bd","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-22 16:29:15.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"146d68c0c09577b6be3dec07e27781ae66eb6efb","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-30 13:38:17.000000000","message":"Uploaded patch set 6: Patch Set 5 was rebased.","accounts_in_message":[],"_revision_number":6},{"id":"f3f1e4d4c1b792deeadad9d502f4f0e5af130b24","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-01 13:53:49.000000000","message":"Uploaded patch set 7: Patch Set 6 was rebased.","accounts_in_message":[],"_revision_number":7},{"id":"cb570512cde499ad4006a234091ae14e820f81f8","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-20 14:49:42.000000000","message":"Uploaded patch set 8.","accounts_in_message":[],"_revision_number":8},{"id":"bc61b9d06d3ba6dfef99f79fefd59ad161b542f8","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-27 18:19:18.000000000","message":"Uploaded patch set 9: Patch Set 8 was rebased.","accounts_in_message":[],"_revision_number":9},{"id":"24f780957108b93cb558bb17dc229111426bd4c7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-29 03:12:52.000000000","message":"Uploaded patch set 10.","accounts_in_message":[],"_revision_number":10},{"id":"bca13db522dd7cba839ee09da8da86accacf5e88","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-04 22:51:55.000000000","message":"Uploaded patch set 11.","accounts_in_message":[],"_revision_number":11},{"id":"a035b49557cd3ca6f9313080dafc0c85f23b05d7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-04 22:52:19.000000000","message":"Uploaded patch set 12: Patch Set 11 was rebased.","accounts_in_message":[],"_revision_number":12},{"id":"12d81c817634cc1b76e6f4bcb9a94abbf4ba5982","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-01-10 08:08:59.000000000","message":"Patch Set 12:\n\n(4 comments)","accounts_in_message":[],"_revision_number":12},{"id":"bc96346f78a7a3b10fe3c5f83f07368612321045","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-10 09:49:02.000000000","message":"Patch Set 12:\n\n(3 comments)","accounts_in_message":[],"_revision_number":12},{"id":"c1b2ebe2aec3e6a1d2214bddd505f23731a42e10","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-10 09:49:11.000000000","message":"Uploaded patch set 13.","accounts_in_message":[],"_revision_number":13},{"id":"2193542e9e1bfcdc151ab2979e199a9c63a2c4f2","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-13 12:09:40.000000000","message":"Uploaded patch set 14.","accounts_in_message":[],"_revision_number":14},{"id":"f374955ebcb23236ac7894a55c5f4cb549052009","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-13 12:14:28.000000000","message":"Uploaded patch set 15.","accounts_in_message":[],"_revision_number":15},{"id":"6702391125c763d6db41a9b4b182c80fe1000d1a","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-16 11:34:05.000000000","message":"Uploaded patch set 16: Patch Set 15 was rebased.","accounts_in_message":[],"_revision_number":16},{"id":"313dbfac16e96bcdf856bb820872ece5b775bc6f","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-03 15:40:48.000000000","message":"Patch Set 16: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":16},{"id":"f329c4559f6f0bb98ecbb53a24bb05fb52d6c660","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-03 18:19:12.000000000","message":"Uploaded patch set 17.\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":17},{"id":"bff47481f37879f527c5024873efbf16240b2510","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 08:32:41.000000000","message":"Patch Set 17: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":17},{"id":"e1df62e43d64f55156c286cf2e7e87dea19d92c3","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-04 08:45:03.000000000","message":"Uploaded patch set 18.\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":18},{"id":"68c46db42af9a0d86b00e404639e043987895560","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 10:56:34.000000000","message":"Patch Set 18: Code-Review-2\n\n(2 comments)","accounts_in_message":[],"_revision_number":18},{"id":"113338a4918fca394476f87b368ac42693244df4","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 10:57:01.000000000","message":"Patch Set 18: Code-Review+1","accounts_in_message":[],"_revision_number":18},{"id":"64140210568e6b9f564873c937266cbe6b1fd19c","author":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"date":"2025-02-05 17:01:22.000000000","message":"Patch Set 18:\n\n(3 comments)","accounts_in_message":[],"_revision_number":18},{"id":"76aa699f790f589d88d5ba994b2dfa139e0098c6","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-05 17:07:25.000000000","message":"Patch Set 18:\n\n(2 comments)","accounts_in_message":[],"_revision_number":18},{"id":"cafb0255a708f18f23ac660e014c75ce42385051","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-07 13:00:06.000000000","message":"Uploaded patch set 19.\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":19},{"id":"b5425082df8feebc996428b2f5f63a8eb5a8a198","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-09 15:27:21.000000000","message":"Patch Set 19: Code-Review+1\n\n(1 comment)","accounts_in_message":[],"_revision_number":19},{"id":"55a954a867fa00f81b02f908bb53c54385177142","author":{"_account_id":1000030,"name":"Max Fillinger","email":"max@max-fillinger.net","username":"MaxF"},"date":"2025-02-12 16:11:24.000000000","message":"Patch Set 19: Code-Review+2\n\n(2 comments)","accounts_in_message":[],"_revision_number":19},{"id":"6741fff70bcd468f4eefe26d3ac5dddcdb2f3431","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-12 18:02:57.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":20}],"current_revision_number":20,"current_revision":"9f4670fc718a8c16280d60c3e2d4ad29cffa04c4","revisions":{"c728823e14163bec77e267694a36412571afc543":{"kind":"REWORK","_number":1,"created":"2024-11-11 01:59:03.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/1","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/1","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/1","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"8d85203f621a2c04e66ef3a5dc2cd2ad46c21565","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 01:50:58.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"cc7cc7a0c7080c8b720276be50c24e1697dceade":{"kind":"REWORK","_number":2,"created":"2024-11-11 16:41:31.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/2","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/2","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/2","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"7318a7bf32b67b4ab6c50f272b8fbc5f4b342fdb","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 16:41:25.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"a791cfd1b161e32cbf022775f3b15bdd23d6579e":{"kind":"REWORK","_number":3,"created":"2024-11-14 13:45:07.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/3","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/3","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/3","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"495cc12515ce2eadd0a92daf5b34df061320fa5c","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-14 13:44:53.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"88a133bf7f33bf10d245193dff1fb8cde581cf06":{"kind":"REWORK","_number":4,"created":"2024-11-15 15:12:22.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/4","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/4","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/4","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5487ed2dedca01c0e579541b15126552d9022d09","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-15 15:12:05.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"86c5d9a765c8bc4f7483f5da717454d96f7c33ab":{"kind":"REWORK","_number":5,"created":"2024-11-22 16:29:15.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/5","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/5","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/5","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3e8c2060cf5103a56e8072942789c2dad0bade76","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-22 16:29:06.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"f2b39e7de7d04a3d921058cbb3fc4171c9d07fce":{"kind":"TRIVIAL_REBASE","_number":6,"created":"2024-11-30 13:38:17.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/6","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/6","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/6","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"8409d04b5c9b8f4d9a40534371e1a4e3db8b24c8","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-30 13:38:01.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"6fd2541b5cc5a7be53d39cde0a6bcd5e6f516bdb":{"kind":"TRIVIAL_REBASE","_number":7,"created":"2024-12-01 13:53:49.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/7","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/7","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/7","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d62dab40e58cf804253c5895cccdd0eff9eb1203","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-01 13:47:59.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"fe530222cd75152ee61e43f9caae2245a00ffe93":{"kind":"REWORK","_number":8,"created":"2024-12-20 14:49:42.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/8","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/8","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/8","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"98159607df3ebf41fb2294180751894f1c8a8427","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-20 14:38:06.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"21d97793733bfc629668f113cf93ba3cd9cda5c5":{"kind":"TRIVIAL_REBASE","_number":9,"created":"2024-12-27 18:19:18.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/9","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/9","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/9","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"4d6c0f48b81102de804f7ac4ed57c8b84ffbba29","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-27 18:18:49.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"bc3044082fd7e30c46424b20fd7b22d85375e9b3":{"kind":"REWORK","_number":10,"created":"2024-12-29 03:12:52.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/10","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/10","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/10","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"71f5c30729ae1741ed6e91302301252a3266f9f8","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-29 03:11:41.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"0b56780729f22a5914449981ab28fcc68f1e0867":{"kind":"REWORK","_number":11,"created":"2025-01-04 22:51:55.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/11","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/11","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/11","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"4e9f618b9bd9f87ebd4d1812d35a2d00896626ef","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-04 22:47:58.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"28d8b5ee153d9a8acaed01e085a2a393b5d7e29f":{"kind":"TRIVIAL_REBASE","_number":12,"created":"2025-01-04 22:52:19.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/12","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/12","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/12","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cef11f0ea7df5ecf91c8100f4aab938d1ad2765b","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-04 22:52:08.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"2280c3317905e09d20317418575b2e3cfb85d921":{"kind":"REWORK","_number":13,"created":"2025-01-10 09:49:11.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/13","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/13","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/13","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"0671a4d009ae89870b645d1a8f3078d9943d5010","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-10 09:49:05.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"adc54228ba88bf134c8100ee3030bfd9c5644350":{"kind":"REWORK","_number":14,"created":"2025-01-13 12:09:40.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/14","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/14","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/14","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5e086c08f2ce4428fd014b74441f0197a71d6da8","subject":"Fix \u0027uninitialized pointer read\u0027 in openvpn_decrypt_aead"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-13 12:09:33.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"607dcaa0a5566aacba01baaed831c421761c2ded":{"kind":"REWORK","_number":15,"created":"2025-01-13 12:14:28.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/15","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/15","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/15","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5e086c08f2ce4428fd014b74441f0197a71d6da8","subject":"Fix \u0027uninitialized pointer read\u0027 in openvpn_decrypt_aead"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-13 12:14:15.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"55972246ccba388d16de72c4950dc319a59de980":{"kind":"TRIVIAL_REBASE","_number":16,"created":"2025-01-16 11:34:05.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/16","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/16","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/16","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6d91eda5a120a4a18273d82fed6777b3efcce8cc","subject":"Fix some trivial sign-compare compiler warnings"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-16 11:22:09.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"29599f765fa30af61ddcbe1bc053fbe13a2b3178":{"kind":"REWORK","_number":17,"created":"2025-02-03 18:19:12.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/17","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/17","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/17","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-03 18:19:00.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"4d7aa213f984614d97673c13a7a2ee57688d925b":{"kind":"REWORK","_number":18,"created":"2025-02-04 08:45:03.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/18","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/18","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/18","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-04 08:44:43.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"7fb4012edb35ce8868d0ef8af270dca3d374532a":{"kind":"REWORK","_number":19,"created":"2025-02-07 13:00:06.000000000","uploader":{"_account_id":1000003,"name":"Arne Schwabe","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/19","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/19","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/19","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-07 12:59:41.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"9f4670fc718a8c16280d60c3e2d4ad29cffa04c4":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":20,"created":"2025-02-12 18:02:57.000000000","uploader":{"_account_id":1000002,"name":"Gert Doering","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"ref":"refs/changes/06/806/20","fetch":{"anonymous http":{"url":"https://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/20","commands":{"Branch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://gerrit.openvpn.net/openvpn refs/changes/06/806/20","Reset To":"git fetch https://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3ddfe26e491f9d74da54feb981116f7b8ef19a70","subject":"Fix oversight of link socket code change in Android code path"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-12 16:13:11.000000000","tz":60},"committer":{"name":"Gert Doering","email":"gert@greenie.muc.de","date":"2025-02-12 16:26:46.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\nAcked-by: MaxF \u003cmax@max-fillinger.net\u003e\nMessage-Id: \u003c20250212161311.16888-1-gert@greenie.muc.de\u003e\nURL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg30845.html\nSigned-off-by: Gert Doering \u003cgert@greenie.muc.de\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[]}