)]}' { "commit": "ea7a88fa5c3841b25cfaa057e023157a54adea46", "tree": "1844d900086dbd2c99244d559ebfe38c00da44ca", "parents": [ "59dd77296d3aa24c8c543e02da0e320bc73a7701" ], "author": { "name": "David Benjamin", "email": "davidben@google.com", "time": "Wed Oct 23 23:48:53 2024 -0400" }, "committer": { "name": "Boringssl LUCI CQ", "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com", "time": "Fri Nov 01 20:55:28 2024 +0000" }, "message": "Stage new DTLS 1.3 read epochs until the first record comes in\n\nIn DTLS 1.2, we install the new read epoch as soon as we change keys,\nand immediately stop accepting data from the previous epoch. This is\nfine because there is only one key change, and we don\u0027t need to receive\ndata from the previous epoch at that point. (Even if we used previous\nflights to trigger retransmits---which we probably should but don\u0027t---I\nbelieve all DTLS 1.2 key changes are such that the previous flight will\ncontain *some* message from the epoch we expect and we can key on that.)\n\nIn DTLS 1.3, things are different. The peer\u0027s KeyUpdates do not apply\nuntil we send an ACK, but that ACK might be lost. So that means, at\nleast for KeyUpdate, we must stage the new epoch and only apply it\nlater.\n\nDuring the handshake, this comes up in two cases:\n\n- A server might send ServerHello..Finished but some of ServerHello (or\n the whole flight) is lost. The server is now expecting\n Certificate..Finished (epoch 2), but the client cannot transition to\n epoch 2 without the ServerHello. The client will then try to induce a\n retransmit by either sending an ACK or resending the ClientHello. The\n client must parse epoch 0 to be able to catch this. This is nice\n but not critical, because the server also has a retransmit timer.\n\n- A client might send Certificate..Finished but it was all lost. The\n client is now done with the handshake (epoch 3), but the server\n cannot complete. The server will then retransmit its\n ServerHello..Finished flight or send an ACK. The ACK will actually\n come at epoch 3, so we don\u0027t need epoch 2 in that case. But the\n retransmit is purely in epochs 0 and 2, so the client must parse\n epoch 2 to catch this. This is also not critical because the\n client is expected to keep its retransmit timer running after the\n handshake (still TODO).\n\nTo support all this, new DTLS 1.3 read epochs are staged until we get a\nrecord.\n\nThis means that record processing must now account for receiving records\nat more epochs, including some invalid cases. Specifically:\n\n- We might receive new handshake messages at the current epoch, even\n though the current epoch is being closed. This is an error.\n\n- We might receive application data at epoch 2 even though we\u0027ve\n finished the handshake and expect it at epoch 3. This is an error.\n\nI\u0027ve added checks for both of these, with tests. This also resolves a\nfew TODOs. The app data check will also help with 0-RTT, where epochs 1\nand 2 will flow concurrently. (We\u0027ll still need an inverse check that\nepoch 1 never carries handshake data.) It also once again changes the\nbroken SSL_get_read_sequence API from one kind of broken to another kind\nof broken, so I\u0027ve updated the comment to explain the current state.\n\nAs part of this, stop tracking read_level and write_level outside of\nQUIC. It\u0027s only used in QUIC and the semantics are a little weird when\nwe defer activating new read epochs.\n\n(I\u0027m not sure whether this behavior is really necessary for epochs\nbefore epoch 3. The only case it accomodates is the client using epoch 0\nto induce a retransmit when ServerHello is lost. The impact it has on\nSSL_get_read_sequence immediately after the handshake is kind of weird,\nso maybe we want to special case it a bit. I can\u0027t think of any case\nwhere we\u0027d want to defer installing epoch 3.)\n\nBug: 42290594\nChange-Id: Id222de2b77ff8e68e64f301f32d8c2b95ad3e7a7\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72450\nReviewed-by: Nick Harper \u003cnharper@chromium.org\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "0b3711fdc346a0756a37823f5519606746ac4999", "old_mode": 33188, "old_path": "ssl/d1_both.cc", "new_id": "0eb39707caa4e9af36c66ec1cde05eb0c218152f", "new_mode": 33188, "new_path": "ssl/d1_both.cc" }, { "type": "modify", "old_id": "9fc854e356ef962cbfd0cedc9a2c09f118e5f1f7", "old_mode": 33188, "old_path": "ssl/dtls_method.cc", "new_id": "ac32346bc049fe0b3174515c2f274baea8e9c3ab", "new_mode": 33188, "new_path": "ssl/dtls_method.cc" }, { "type": "modify", "old_id": "8a17ee299d46754ccff9aa6fca9589ff8955776c", "old_mode": 33188, "old_path": "ssl/dtls_record.cc", "new_id": "3d381fbb63b63ffec9b6e59bebbe30c6f0d5401c", "new_mode": 33188, "new_path": "ssl/dtls_record.cc" }, { "type": "modify", "old_id": "15634d6f8be66e3c240da595caba85fc9560bb97", "old_mode": 33188, "old_path": "ssl/internal.h", "new_id": "636decfbdac22016e71f51aebb03f3d14a1a8f08", "new_mode": 33188, "new_path": "ssl/internal.h" }, { "type": "modify", "old_id": "8110725a3de99e7e996d9bc4fcf554f2eba3abec", "old_mode": 33188, "old_path": "ssl/s3_both.cc", "new_id": "4ece96d51cd2e34334dec135be2bb25e703e6471", "new_mode": 33188, "new_path": "ssl/s3_both.cc" }, { "type": "modify", "old_id": "a34c5a648866ddd61436837c4daa001102465b6e", "old_mode": 33188, "old_path": "ssl/s3_pkt.cc", "new_id": "83ec13d88e642eab44632d46a7b4c946699a35b6", "new_mode": 33188, "new_path": "ssl/s3_pkt.cc" }, { "type": "modify", "old_id": "e74f8866efebc36b574999fa3c0c51f2f7ac82b7", "old_mode": 33188, "old_path": "ssl/ssl_lib.cc", "new_id": "f52030b8cd97d24d805963fd86a9e2b0da15af48", "new_mode": 33188, "new_path": "ssl/ssl_lib.cc" }, { "type": "modify", "old_id": "e31c532b61830ee1a8e8a8b31af670690ba1b06f", "old_mode": 33188, "old_path": "ssl/ssl_test.cc", "new_id": "a4fedd890782cb1c915ebc3429869021a4b0b260", "new_mode": 33188, "new_path": "ssl/ssl_test.cc" }, { "type": "modify", "old_id": "b5bf78345712f6918fdb87f5b9ee16ce721e1db7", "old_mode": 33188, "old_path": "ssl/test/runner/common.go", "new_id": "64a02e5030ccdbc4856e9fa683f343131d325085", "new_mode": 33188, "new_path": "ssl/test/runner/common.go" }, { "type": "modify", "old_id": "6967ae7e34b3b65a88ed0392af680e2b9caa5c4a", "old_mode": 33188, "old_path": "ssl/test/runner/fuzzer_mode.json", "new_id": "f895546c69ada185c033af4b70efaf9c56972377", "new_mode": 33188, "new_path": "ssl/test/runner/fuzzer_mode.json" }, { "type": "modify", "old_id": "b31d636c3d25da2a69359ef3f8ad86c6f5b559aa", "old_mode": 33188, "old_path": "ssl/test/runner/handshake_client.go", "new_id": "5281c7a49cdf2741834f359ca2ab1650f073300d", "new_mode": 33188, "new_path": "ssl/test/runner/handshake_client.go" }, { "type": "modify", "old_id": "2b910aa9a276477f5319ff9eb7e0d446a231bb0a", "old_mode": 33188, "old_path": "ssl/test/runner/handshake_server.go", "new_id": "1eaef77b4859de06e145153e49ce2a96e458134e", "new_mode": 33188, "new_path": "ssl/test/runner/handshake_server.go" }, { "type": "modify", "old_id": "8c745e3678103399e21f9cf28cf617129744d077", "old_mode": 33188, "old_path": "ssl/test/runner/runner.go", "new_id": "41a75b11648d7a885cdfaa2c2408afea2b6dd26e", "new_mode": 33188, "new_path": "ssl/test/runner/runner.go" }, { "type": "modify", "old_id": "7082d16ee3690cbae3968be7f728d50bb117ecad", "old_mode": 33188, "old_path": "ssl/tls13_client.cc", "new_id": "4972fbe3d99f1a39c14a2bb9258c2f8fcc25a9df", "new_mode": 33188, "new_path": "ssl/tls13_client.cc" }, { "type": "modify", "old_id": "0a3fc4e4d3e9d8f84a2f45e593039fdd0a49b171", "old_mode": 33188, "old_path": "ssl/tls_method.cc", "new_id": "2de7ad1a0df42cdcdcb2774cf537ae74c77775c0", "new_mode": 33188, "new_path": "ssl/tls_method.cc" } ] }