[TLS] [Errata Verified] RFC7366 (4212)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 30 March 2015 23:05 UTC

To: pgut001@cs.auckland.ac.nz, pgut001@cs.auckland.ac.nz
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20150330230514.09F3A18046C@rfc-editor.org>
Date: Mon, 30 Mar 2015 16:05:14 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CKriothyK0Vk7lYltjpF06MLbfw>
Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org
Subject: [TLS] [Errata Verified] RFC7366 (4212)
Precedence: list

The following errata report has been verified for RFC7366,
"Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7366&eid=4212

--------------------------------------
Status: Verified
Type: Technical

Reported by: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date Reported: 2014-12-27
Verified by: Stephen Farrell (IESG)

Section: 3

Original Text
-------------
   In TLS [2] notation, the MAC calculation for TLS 1.0 without
   the explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       ENC(content + padding + padding_length));

   and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       TLSCipherText.length +
       IV +
       ENC(content + padding + padding_length));


Corrected Text
--------------
Note that the length value used for the MAC computation differs from 
the value of the 'uint16 length' field in the TLSCiphertext record as 
encoded on the wire.  The encoded TLSCiphertext record contains both 
the ciphtertext and the MAC, while the MAC calculation is performed 
only over the ciphertext.  The length value encoded in the 
TLSCiphertext record is therefore 'length' while the length value 
used in the MAC calculation is 'length - SecurityParameters.mac_length'.

More formally, if:

  TLSCiphertext.enc_content = ENC(content + padding + padding_length)

then in TLS notation the MAC calculation for TLS 1.0 without the 
explicit Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (TLSCiphertext.enc_content) +
       TLSCiphertext.enc_content);

and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + TLSCiphertext.enc_content) +
       IV +
       TLSCiphertext.enc_content);


Notes
-----
After the RFC was published a new set of implementers (who hadn't been part of the pre-publication interop testing) pointed out that the text covering the use of length values could be interpreted in two different ways.  This correction attempts to remove the ambiguity by making explicit what's MACd vs. what's encoded on the wire.

--------------------------------------
RFC7366 (draft-ietf-tls-encrypt-then-mac-03)
--------------------------------------
Title               : Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Publication Date    : September 2014
Author(s)           : P. Gutmann
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

[TLS] [Errata Verified] RFC7366 (4212) RFC Errata System
[TLS] [Technical Errata Reported] RFC7366 (4212) RFC Errata System