Re: [TLS] rfc7366: is encrypt-then-mac implemented?

"Yngve N. Pettersen" <yngve@spec-work.net> Sat, 01 November 2014 19:25 UTC

Return-Path: <yngve@spec-work.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124001A0396 for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 12:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YndZJ-p3E_z for <tls@ietfa.amsl.com>; Sat, 1 Nov 2014 12:25:47 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2274B1A0390 for <tls@ietf.org>; Sat, 1 Nov 2014 12:25:46 -0700 (PDT)
Received: from 151.170.251.212.customer.cdi.no ([212.251.170.151]:52511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <yngve@spec-work.net>) id 1XkeIy-0002G7-Sv for tls@ietf.org; Sat, 01 Nov 2014 20:25:44 +0100
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
Date: Sat, 01 Nov 2014 20:25:32 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.xonuwux33dfyax@killashandra.invalid.invalid>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KVtX4BW67fZeIYnatUYS1mVKFtc
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Nov 2014 19:25:50 -0000

Hi,

Warning, long post.

For reference, I have tried to implement RFC 7366 in my TLS Prober, but I  
have not been able to establish a connection with the "eid" server. It  
seems to have some non-standard requirements to the client that AFAICT  
have not been documented anywhere.


On Wed, 29 Oct 2014 15:38:41 +0100, Peter Gutmann  
<pgut001@cs.auckland.ac.nz> wrote:

> Manuel Pégourié-Gonnard <mpg@polarssl.org> writes:
>
>> What I'm doing to get this is interpret TLSCipherText.length exactly as  
>> it is
>> defined in RFC 5246 (6.2.3.2, page 22):
>>
>>   The encrypted data length (TLSCiphertext.length) is one more than the
>>   sum of SecurityParameters.block_length, TLSCompressed.length,
>>   SecurityParameters.mac_length, and padding_length.
>>
>> Apparently to interoperate with the implementation at eid.vx4.net (and  
>> with
>> OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
>> SecurityParameters.mac_length. I couldn't find this explicitly stated
>> anywhere.
>
> Section 3 of RFC 7366 says:
>
>   In [2] notation the overall packet is then:
>
>    struct {
>           ContentType type;
>           ProtocolVersion version;
>           uint16 length;
>           GenericStream/BlockCipher fragment;
>           opaque MAC;
>           } TLSCiphertext;
>
>    This is identical to the existing TLS layout with the only difference
>    being that the MAC value is moved outside the encrypted data.

I am starting to wonder if the confusion about this spec update is partly  
due to the way the record structure is defined, with the length separate  
 from the data vectors. This separation have been a problem in connection  
with at least some extensions.

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.

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;

   struct {
      opaque plaintext[TLS_Record.record_data.length];
   } TLS_Plaintext_data;

   stream-ciphered struct {
      opaque [TLS_Record.record_data.length-MAClength];
      opaque MAC[MAClength];
   } TLS_Stream_Encrypted_data;

   struct {
      opaque IV[SecurityParameters.record_iv_length];
      block_encrypted_stream  struct {
         opaque  
[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1];
         opaque MAC[MAClength];
         uint8 padding [paddinglength];
         uint8 paddinglength;
      } encrypted;
   } TLS_Block_Encrypted_data;

With RFC7366 the format for the encrypted record payloads got changes, and  
it seems to me that the problem is a disagreement of what the length field  
in the TLSCipherText record applies to.

In the following I will assume that we (the TLS WG) while implementing  
peers that understand the Encrypt then MAC record format, also wants to  
Maintain backwards compatibility with all existing infrastructure (such as  
firewalls) that processes the TLS ciphertext records, but which do not  
know about RFC 7366.

Given these requirment, I think the TLS_Record_payload structure have to  
be redefined as

   struct {
     select(encryption_mode) {
        case plaintext: TLS_Plaintext_data;
        case stream_encrypted: TLS_EtM_Stream_Encrypted_data;
        case block_encrypted: TLS_EtM_Block_Encrypted_data;
     }
   } TLS_Record_payload;

   struct {
      stream-ciphered opaque  
fragment[TLS_Record.record_data.length-MAClength];
      opaque MAC[MAClength]
   } TLS_EtM_Stream_Encrypted_data;

   struct {
      opaque IV[SecurityParameters.record_iv_length];
      block-ciphered struct {
        opaque  
fragment[TLS_Record.record_data.length-SecurityParameters.record_iv_length-MAC-paddinglength-1];
        uint8 padding [paddinglength];
        uint8 paddinglength;
      } encrypted;
      opaque MAC[MAClength];
   } TLS_EtM_Block_Encrypted_data;

I think one thing that is to be determined is whether this rewritten  
structure definitions accurately describes both the old format and the new  
RFC 7366 format. Do they?

If RFC 7366 means to say that the MAC field is no longer part of the  
record_data field (and not counted in the length field), then that is  
going to cause trouble, because processors that are not aware of the  
extension will then read the first bytes of the MAX as the ContentType  
field and the version field, probably resulting in a connection closure.

The second issue that seems to have developed is which value to use as the  
length part of the MAC calculation.

RFC 7366 version:

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

Adapted to my rewritten structure the question is if the MAC (for block  
cipher encryption) is calculated as

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

or

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

As written, as I understand it, and assuming compatibility with ignorant  
intermediates, RFC 7366 specifies the first formula.

However, I have the impression that some think that either 1) the MAC  
field is not part of the bytes counted as TLSCipherText.length or 2) the  
length field in the MAC is really the length of the fragment field.

IMO case 1 will lead to interoperability problems with intermediates, and  
case 2 is not what the specification says if we assume interoperability.

I think that before we continue the discussion we need to decide what the  
record format is on the wire, and if it is compatible with the old format,  
or not. Then we need to decide which value is used in the MAC formula.

My suggestion for an answer to the first question is that we have to  
maintain backwards compatibility with ignorant intermediates, which means  
that TLSCipherText.length MUST count the MAC bytes, not just the fragment  
(including padding).

Regarding the second question, IMO it does not really matter much which  
value is used. However, it is probably easier to use the length of the  
encrypted block, rather than TLSCipherText.length, since  
TLSCipherText.length have to be calculated instead of derived from the  
MACed encrypted block.


Given the current confusion we need at least an errata that accurately  
specifies which values include which data.

However, given that such changes may modify the meaning more than a normal  
errata do, perhaps a better idea is a new RFC that either replace RFC 7366  
or one that specifies a new extension ID and deprecate the old one, so  
that we reduce the potential for confusion among implementations? After  
all, some implementers might miss the existence of the errata, and in this  
case the errata would be important for the proper understanding of the  
specification.


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/