Closed Bug 972145 Opened 6 years ago Closed 3 years ago

Implement the encrypt-then-MAC TLS extension


(NSS :: Libraries, enhancement, P2)



(Not tracked)



(Reporter: wtc, Assigned: wtc)



(1 file)

The attached patch is a preliminary implementation of the encrypt-then-MAC
TLS extension proposed by Peter Gutmann:

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, I had to pass
    the length of TLSCiphertext.fragment
instead of
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:
Any progress on this?
Flags: needinfo?(wtc)
I'd like to mention the recent thread on the TLS mailing list about that:

Short version: the text in the RFC didn't unambiguously express the intention of the author. The implementation cited above ( 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.
Closed: 3 years ago
Flags: needinfo?(wtc)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.