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

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 02 March 2015 16:41 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: <20150302164037.95B8F181D1B@rfc-editor.org>
Date: Mon, 02 Mar 2015 08:40:37 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TAWQW7kK_ihqGCwGbdT45oSnV2o>
Cc: dottomi@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC7366 (4284)
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=4284

--------------------------------------
Type: Technical
Reported by: Tomasz Sobczyk <dottomi@gmail.com>

Section: 3

Original Text
-------------
The overall TLS packet [2] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

   The equivalent DTLS packet [4] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 epoch;
          uint48 sequence_number;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

   This is identical to the existing TLS/DTLS layout, with the only
   difference being that the MAC value is moved outside the encrypted
   data.


Corrected Text
--------------
   The overall TLS packet [2] is then:
   
   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC[SecurityParameters.mac_length];
   } TLSCiphertext;

   The equivalent DTLS packet [4] is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 epoch;
          uint48 sequence_number;
          uint16 length;
          GenericBlockCipher fragment;
          opaque MAC[SecurityParameters.mac_length];
   } TLSCiphertext;

   This is identical to the existing TLS/DTLS layout, with the only
   differences being that the MAC value is moved outside the encrypted
   data and the definition of TLSCiphertext.length changes to:

   length
      The length (in bytes) of the following TLSCiphertext.fragment
      and TLSCiphertext.MAC.
      The length MUST NOT exceed 2^14 + 2048.


Notes
-----
MAC array length is missing.
Also, the new structure changes the definition of TLSCiphertext.length.
As it currently stands, the length of the MAC is excluded from TLSCiphertext.length.

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 Rejected] RFC7366 (4284) RFC Errata System
Re: [TLS] [Errata Rejected] RFC7366 (4284) Megan Ferguson
[TLS] [Technical Errata Reported] RFC7366 (4284) RFC Errata System