972145 - Implement the encrypt-then-MAC TLS extension

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P2)

Description

[Wan-Teh Chang]

Attachment: Patch (work in progress)

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 1

[Wan-Teh Chang]

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/

Comment 2

[nicoo]

Any progress on this?

Comment 3

[mpg]

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.

Comment 4

[Mathias]

Just out of curiosity, is this request definitely stalled?

Comment 5

[Eric Rescorla (:ekr)]

(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.

Comment 6

[Franziskus Kiefer [:franziskus]]

As ekr said, this probably not worth doing at this point. Let's close this as won't fix.