[TLS] [Technical Errata Reported] RFC7366 (4212)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 27 December 2014 12:29 UTC

To: pgut001@cs.auckland.ac.nz, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20141227122817.8D2F3181C67@rfc-editor.org>
Date: Sat, 27 Dec 2014 04:28:17 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ir9BiN-5qboWFzJdk154L2ogMAg
Cc: rfc-editor@rfc-editor.org, tls@ietf.org
Subject: [TLS] [Technical Errata Reported] RFC7366 (4212)
Precedence: list

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Peter Gutmann <pgut001@cs.auckland.ac.nz>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

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