Re: [TLS] rfc7366: is encrypt-then-mac implemented? (Martin Rex) Wed, 05 November 2014 23:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9FF211A0368 for <>; Wed, 5 Nov 2014 15:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rw4deHJT1qiB for <>; Wed, 5 Nov 2014 15:58:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 930B81A032D for <>; Wed, 5 Nov 2014 15:58:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBBF23A1D0; Thu, 6 Nov 2014 00:58:23 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 98FE14196E; Thu, 6 Nov 2014 00:58:23 +0100 (CET)
Received: by (Postfix, from userid 10159) id 943381AF95; Thu, 6 Nov 2014 00:58:23 +0100 (CET)
In-Reply-To: <op.xonuwux33dfyax@killashandra.invalid.invalid>
To: "Yngve N. Pettersen" <>
Date: Thu, 06 Nov 2014 00:58:23 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Nov 2014 23:58:27 -0000


Yngve N. Pettersen wrote:
> The way a TLS Protocol record is defined in previous versions (Using TLS  
> 1.2), before this update is, can a generic way be rewritten as:
>    struct {
>         ContentType type;
>         ProtocolVersion version;
>         opaque record_data<0..maxlength>
>    } TLS_Record;
> This is how all clients and servers will parse current SSL and TLS  
> versions' records on the wire, and also how all the intermediate servers  
> (the ones that are causing concern for version rollback recovery) will be  
> parsing the TLS traffic.

Thanks for your elaborate discussion.

I agree with many parts of your root cause analysis why the content
of rfc7366 is a failure (beyond fixing through the errata process).

I wrote a similar (much less elaborate) observation to Peter a day
earlier (in a private mail), that the root cause of the confusion
is likely the goof of the original SSLv3 and successor specs
in failing to correctly specify the outer TLS protocol PDU
and properly modeling of the inner PDU variations within
the correct framework.

   struct {
        ContentType type;
        ProtocolVersion version;
        opaque record_data<0..(2^14+2048)>
   } TLS_Record;

It doesn't really matter whether the seriously misleading and
backwards-incompatible protocol in rfc7366 could be hacked to
produce the same "bits-on-the-wire" as what was actually intended
protocol-wise, by frobbing the semantics and content of the
length field of the redefined rfc7366 TLSCiphertext and frobbing
the MAC computation.

> The field record_data containing a strucure of exactly the length of  
> record_data
>    struct {
>      select(encryption_mode) {
>         case plaintext: TLS_Plaintext_data;
>         case stream_encrypted: TLS_Stream_Encrypted_data;
>         case block_encrypted: TLS_Block_Encrypted_data;
>      }
>    } TLS_Record_payload;

Your picture is lacking the TLSCompressed structure, which (although 
not used very often these days) is still a regular part of the
SSLv3 and TLSv1.[012] protocols.

One of my complaints about rfc7366 was to redefine the GenericBlockCipher
PDU in a backwards-incompatible fashion, and actually use *TWO DIFFERENT*
PDUs, rather than a single combined one.  It is extremely silly to
carry through the IV-less TLSv1.0 PDU on a backwards-incompatible
PDU change, because this will require _more_ code and _repeat_ a
known security problem in an alleged protocol security fix.