Closed Bug 972145 Opened 6 years ago Closed 3 years ago
Implement the encrypt-then-MAC TLS extension
The attached patch is a preliminary implementation of the encrypt-then-MAC TLS extension proposed by Peter Gutmann: http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05 The patch is not yet polished. It is also missing the server-side extension sender and handler functions. In order to interoperate with the test server at https://eid.vx4.net:443/, I had to pass the length of TLSCiphertext.fragment instead of TLSCipherText.length to the MAC function.
Comment on attachment 8375259 [details] [diff] [review] Patch (work in progress) This patch can be browsed at the Chromium code review site: https://codereview.chromium.org/166273026/
Any progress on this?
I'd like to mention the recent thread on the TLS mailing list about that: https://www.ietf.org/mail-archive/web/tls/current/msg14177.html Short version: the text in the RFC didn't unambiguously express the intention of the author. The implementation cited above (eid.vx4.net) matches the intention of the RFC author. An erratum will be added shortly to clarify the situation, by specifying that the length in the input to the MAC function must be the length of "IV + ENC(content + padding + padding_length)" (without the IV for TLS 1.0 obviously). I think this new information make it possible to move forward with this bug.
Just out of curiosity, is this request definitely stalled?
(In reply to Mathias from comment #4) > Just out of curiosity, is this request definitely stalled? Yes, I don't expect us to land this patch. We've pretty much transitioned to AEAD both for TLS 1.2 and TLS 1.3.
As ekr said, this probably not worth doing at this point. Let's close this as won't fix.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.