Subject: Re: [TLS] [Errata Rejected] RFC7366 (4284)

From: Megan Ferguson <[email-masked]>
Date: Wed, 1 Apr 2015 12:42:22 -0400

Greetings,

This erratum has been deleted as requested.

Thank you.

RFC Editor/mf

On Mar 30, 2015, at 7:06 PM, RFC Errata System <[email-masked]> wrote:

> The following errata report has been rejected 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
> 
> --------------------------------------
> Status: Rejected
> Type: Technical
> 
> Reported by: Tomasz Sobczyk <[email-masked]>
> Date Reported: 2015-03-02
> Rejected by: Stephen Farrell (IESG)
> 
> 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.
> This is a duplicate of erratum 4212 which is now verified.
> --VERIFIER NOTES-- 
>    This is a duplicate of erratum 4212 which is now verified. 
> 
> --------------------------------------
> 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
>