)]}'
{
  "commit": "52d5e1b6d3f0669868f0ba95792b527907a67fdd",
  "tree": "d126f85de8d62589d346ae399ed6aaa28646d248",
  "parents": [
    "e4978786daee58f51dcb98bc9665883d6f8567c0"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Tue Oct 22 14:34:34 2024 -0400"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Thu Oct 24 20:08:58 2024 +0000"
  },
  "message": "Never reconstruct 1.3 record numbers above 2^48-1\n\nIn DTLS 1.2, it was syntactically impossible to make a record number\nover 2^48-1 or an epoch number over 2^16-1. This was nice because it\nmeant record numbers could be packed into an 8-byte structure.\n\nDTLS 1.3 attempted to lift these constraints, but ineffectively. The\nepoch count cannot go past 2^16-1 due to how the message number works.\nThe outgoing record count has no reason to exceed 2^48-1 because we\nwould have to send 5 petabytes to count that high even with empty\nrecords, and indeed we check this right now.\n\nThe incoming record count is complicated. Record number reconstruction\n*could* count that high if we receive 2^33 records (the max we can jump\nis 2^15 at a time). This is within the realm of possibility for an\nattacker, but too high to practically count via unit tests, and useless\nfor a well-behaved sender because the sender has no reason to skip\nsequence numbers.\n\nThe result is that we need to use more memory and worry about a case\nthat we cannot practically test, which is only useful for attackers.\nThis is not useful. Instead, change the record number reconstruction\nlogic to never give back record numbers past 2^48. If the peer manages\nto send 5 petabytes and count that high without rekeying, we\u0027ll jam the\nrecord number and start dropping those packets. An error would be\npreferable, but that would be a codepath we cannot effectively test, so\nI opted to just bodge the reconstruction logic.\n\nWith this done, we can pack the record numbers again. The next CL will\nintroduce a DTLSRecordNumber type to abstract the various bit\nmanipulations we\u0027ve been doing.\n\nBug: 42290594\nChange-Id: I8bb0584a792578cf1d2a9df0b0c035d794c85beb\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72270\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Nick Harper \u003cnharper@chromium.org\u003e\nCommit-Queue: Nick Harper \u003cnharper@chromium.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "911dcc658a95e6d6ef20e5689b35dd2b499ce412",
      "old_mode": 33188,
      "old_path": "ssl/dtls_record.cc",
      "new_id": "f769696180afbec3a7d5d33dc07c9079b9718cd9",
      "new_mode": 33188,
      "new_path": "ssl/dtls_record.cc"
    },
    {
      "type": "modify",
      "old_id": "29a674cb837aeb45c089a9e63f10552e2e982085",
      "old_mode": 33188,
      "old_path": "ssl/internal.h",
      "new_id": "0f3bd8229643207b312dcf1add14b43b76e0bf53",
      "new_mode": 33188,
      "new_path": "ssl/internal.h"
    },
    {
      "type": "modify",
      "old_id": "2cca65a655e0b8af5ae85548608d697cff00cd14",
      "old_mode": 33188,
      "old_path": "ssl/ssl_internal_test.cc",
      "new_id": "b6abafdfe4d29ad2577cecd869d373351a83d0eb",
      "new_mode": 33188,
      "new_path": "ssl/ssl_internal_test.cc"
    }
  ]
}