)]}'
{
  "commit": "80defe9243d57cf50636aa9a21f2ac18a9326b3f",
  "tree": "d02d0f12579ccee837c638786ee49ace27cf548b",
  "parents": [
    "c4e48bae3d0c07114b3724578fcf4652c19d178f"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Thu Dec 05 17:57:03 2024 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Fri Dec 06 22:18:02 2024 +0000"
  },
  "message": "Correctly re-ACK client Finished in DTLS 1.3\n\nIf client Finished gets through, but the server\u0027s responding ACK is\nlost, the client will retransmit Finished (epoch 2). The server must\nthen process that retransmission and send another ACK.\n\nHowever, the client may have since sent application data (epoch 3),\nwhich the server may have since processed. Despite receiving data at\nepoch 3, the server must keep epoch 2 open for some period of time to\naccomodate this.\n\nUnfortunately, there is no explicit signal in the protocol to do this.\nThe best we have is some guidance to be willing to do this for at least\n2x MSL. See this discussion in the TLS mailing list:\nhttps://mailarchive.ietf.org/arch/msg/tls/rof4SqkDrwU8o7WqSa9AO3YEUJI/\n\nImplement this by keeping old epochs around for 2x MSL. This has the\nside effect of also keeping old epochs around for a spell on KeyUpdate,\nmaking us more resilient to packet reordering around KeyUpdate. For\nsimplicity, I\u0027ve just get the same timeout for both, 2x MSL, or 4\nminutes.\n\nThis opens a few cans of worms, because now record processing logic must\naccomodate old epochs:\n\n- The check against fragments from old epochs gets more complex.\n\n- The check for maximum message size must move later; after the\n  handshake, the server has a tight maximum message size, but it must be\n  willing to receive (and skip over) retransmits from before the\n  handshake when the limit was higher.\n\n- Application data is fine. We already, at a lower layer, forbid any\n  application data from coming in epochs 0 and 2.\n\n- The ACK logic already did not make any particular assumptions here.\n  Now we\u0027ll process ACKs from older epochs for slightly longer, but we\n  already check that old epochs cannot ACK new epochs\u0027 messsages.\n\n- ChangeCipherSpec is silly and would probably become moot once we start\n  rejecting CCS in DTLS 1.3, but I just made it drop old epochs CCS on\n  the floor to match the old behavior for now. (May as well avoid\n  relying too much on DTLS 1.2 keeping one epoch around at once.)\n\nThis also requires tweaking the test slightly. flushHandshake needs to\nrun after the application data keys are installed, or the callback\ncannot send data. That, in turn, means OutEpoch() is no longer the right\nepoch for sending an ACK so some of the tests need to be updated to\nstill pick up epoch 2. (What\u0027s going on is that sending ACKs happens\nbefore you construct the flight, but we want to test reordering, so we\nsimulate it afterwards.)\n\nBug: 42290594\nChange-Id: I199b304fa9c3d8d252d258ab8ff231e3b5688e2e\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74027\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Nick Harper \u003cnharper@chromium.org\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "db51c9a36c373bf5c752d8ce74a92d27d9f93d6f",
      "old_mode": 33188,
      "old_path": "ssl/d1_both.cc",
      "new_id": "648bd66db73d9e080a9303c20b667d81bda9ffaa",
      "new_mode": 33188,
      "new_path": "ssl/d1_both.cc"
    },
    {
      "type": "modify",
      "old_id": "5b124d9a048640360f4f6ab48b9cba1c6469cd81",
      "old_mode": 33188,
      "old_path": "ssl/dtls_record.cc",
      "new_id": "1bfc43f6a6d2c72f8103f6c54189690a8aad9010",
      "new_mode": 33188,
      "new_path": "ssl/dtls_record.cc"
    },
    {
      "type": "modify",
      "old_id": "b2eb5647e6e9c81fa6f51e2a1da70579aba0a759",
      "old_mode": 33188,
      "old_path": "ssl/internal.h",
      "new_id": "eab3af72863660431e4f9ddd17e566f9bebe2c0c",
      "new_mode": 33188,
      "new_path": "ssl/internal.h"
    },
    {
      "type": "modify",
      "old_id": "76195f6f3f499f448a52eeed75a7829be8e6e10a",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/common.go",
      "new_id": "7dfba1416e0ac857aed092171424f76819589405",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/common.go"
    },
    {
      "type": "modify",
      "old_id": "454333983360240891e5ed8e6744ede4604b1b70",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/handshake_client.go",
      "new_id": "b6b95156ed8a0a323bba8c1fa516e42aed5c5eab",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/handshake_client.go"
    },
    {
      "type": "modify",
      "old_id": "fe9c1bdafa03c5ae8386a1acb02b1bda1f739577",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/runner.go",
      "new_id": "ddd665a6559694b5d1222647312bfe7433bf9a4d",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/runner.go"
    }
  ]
}