)]}' { "commit": "a0b324f96615bdca7bd048f23589a2445ccdc6a4", "tree": "a477881ec9b69def80eb04e933a0c626b83f82f8", "parents": [ "f8cadd89744dffe7a566c458b80bf2846f213ff1" ], "author": { "name": "David Benjamin", "email": "davidben@google.com", "time": "Mon Sep 23 17:08:40 2024 -0400" }, "committer": { "name": "Boringssl LUCI CQ", "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com", "time": "Thu Oct 03 19:54:57 2024 +0000" }, "message": "Remove redudant version information from SSLAEADContext\n\nAfter https://boringssl-review.googlesource.com/c/boringssl/+/71533, it\nis never the case that we have two version\u0027s worth of the record layer\nalive at once. This means we stop needing to store a version number in\nthe epoch state, or worry about which version we check if in theory the\nconnection and each epoch are in different states. (I\u0027m not sure how\nDTLS 1.3 ACKs will possibly work in such a model.)\n\nSimply this by taking versions out of the epochs and instead having\neverything check the connection\u0027s version. For that to work, we need to\nrelax the invariants on the version slightly. When we enter 0-RTT, we\nset the version to the 0-RTT version. The final version will then either\nmatch or trigger a 0-RTT reject before changing the version. Having the\nversion change is unfortunate but it reflects what\u0027s going on.\n\nAs a result, some checks added for DTLS 1.3 will now behave correctly\nwith DTLS 1.3 0-RTT. This also simplifies things slightly along the way\nto cleaning up the epoch state to implement DTLS 1.3 ACKs.\n\nThere are two checks that arguably did not want to pay attention to the\n0-RTT version, but the difference seems unimportant. But, for\ncompleteness:\n\n1. If we offer 0-RTT, the logic to ignore dummy ChangeCipherSpec records\n deep in the record layer will kick in before the ServerHello, instead\n of after. This is arguably supported by RFC 8446, which says any time\n after the first ClientHello suffices:\n\n \u003e An implementation may receive an unencrypted record of type\n \u003e change_cipher_spec consisting of the single byte value 0x01 at any\n \u003e time after the first ClientHello message has been sent or received\n \u003e and before the peer\u0027s Finished message has been received and MUST\n \u003e simply drop it without further processing.\n\n Though that guidance is pretty bizarre because we haven\u0027t learned the\n version yet before ServerHello. Anyway, I don\u0027t think this has any\n real practical impact and isn\u0027t worth fussing over.\n\n2. If we offer 0-RTT, the logic to treat a \"warning\" decode_error alert\n as fatal will kick in before the ServerHello, instead of after. If\n the server deployed 0-RTT, then rolled back to TLS 1.2 (against the\n guidance in Appendix D.3 but possible), AND if it sent a warning\n alert before the TLS 1.2 ServerHello, we would fail the connection\n with a different error and not trigger the application\u0027s retry.\n\n This also does not seem worth fussing over.\n\nBug: 42290594\nChange-Id: I8d97e219888c75274c3c640b2da5c769c6b9ad36\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71534\nCommit-Queue: Bob Beck \u003cbbe@google.com\u003e\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\n", "tree_diff": [ { "type": "modify", "old_id": "4caadad6ec39c4446980af76eecce2231cb2b844", "old_mode": 33188, "old_path": "ssl/d1_lib.cc", "new_id": "4aa71acc1d65821b21766cbd71c9b2d683f4721f", "new_mode": 33188, "new_path": "ssl/d1_lib.cc" }, { "type": "modify", "old_id": "ba06acf96aabb952c2264265dbf43931b2bb7bad", "old_mode": 33188, "old_path": "ssl/dtls_record.cc", "new_id": "479ecd4b8aee7d061174faed70eb3d89b2f1db81", "new_mode": 33188, "new_path": "ssl/dtls_record.cc" }, { "type": "modify", "old_id": "438f89904d44e77f5f1c4bef209c3dc54a2eb92f", "old_mode": 33188, "old_path": "ssl/handoff.cc", "new_id": "ec950d038859faa58f500645ae12bb3ea5752d33", "new_mode": 33188, "new_path": "ssl/handoff.cc" }, { "type": "modify", "old_id": "82c4df941f8fac367e714950e3e4c549090aed7a", "old_mode": 33188, "old_path": "ssl/handshake_client.cc", "new_id": "2f74ff56dafaaa12e6534559e90063871ec259f1", "new_mode": 33188, "new_path": "ssl/handshake_client.cc" }, { "type": "modify", "old_id": "4b68ebcf939b0386311d32e9d7d17c5e7e511e9f", "old_mode": 33188, "old_path": "ssl/handshake_server.cc", "new_id": "7821ce09317167769e54ebfb25789ca6dbbabe49", "new_mode": 33188, "new_path": "ssl/handshake_server.cc" }, { "type": "modify", "old_id": "30e610407a91d6ba629cd2f3ba61e4ee4e67a94f", "old_mode": 33188, "old_path": "ssl/internal.h", "new_id": "4bbbeb7389559e1db8f0172b83c2aa4959e485c3", "new_mode": 33188, "new_path": "ssl/internal.h" }, { "type": "modify", "old_id": "472d1ab1fb277620a6e82f7afd47c1d1c0f5c7da", "old_mode": 33188, "old_path": "ssl/s3_lib.cc", "new_id": "14d9b640ce0d48e10294007fb02c0a47f2b1fbec", "new_mode": 33188, "new_path": "ssl/s3_lib.cc" }, { "type": "modify", "old_id": "5079ca2d17f0a9799ed7b5f75d2a4139244f4504", "old_mode": 33188, "old_path": "ssl/ssl_aead_ctx.cc", "new_id": "652a5e9cafdf7e699d8d56583b6c5af084b61da1", "new_mode": 33188, "new_path": "ssl/ssl_aead_ctx.cc" }, { "type": "modify", "old_id": "650a0b62f1706668297c2d96fd5e382d94a77369", "old_mode": 33188, "old_path": "ssl/test/runner/runner.go", "new_id": "e598ac7b037a3e2ef67f502bb77784109d466f09", "new_mode": 33188, "new_path": "ssl/test/runner/runner.go" }, { "type": "modify", "old_id": "766013f0fa4faca4455ce88fa13c44e295c3c24f", "old_mode": 33188, "old_path": "ssl/tls13_client.cc", "new_id": "fd9ab0aa8a20ce477c3f649abbe5b2481b19ab13", "new_mode": 33188, "new_path": "ssl/tls13_client.cc" }, { "type": "modify", "old_id": "4a642da7ca6acc620051df8943d4173c5929098f", "old_mode": 33188, "old_path": "ssl/tls13_enc.cc", "new_id": "19631f55994bf6221e84b6a2d39bb6030a4c095b", "new_mode": 33188, "new_path": "ssl/tls13_enc.cc" }, { "type": "modify", "old_id": "6e2bdd408c1b22b324a0237006d542b68b60b1b9", "old_mode": 33188, "old_path": "ssl/tls_record.cc", "new_id": "685b78ae9db39138f4c27579dd450883099a03d9", "new_mode": 33188, "new_path": "ssl/tls_record.cc" } ] }