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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 30 October 2014 13:40 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 A113F1A0053 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 06:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level:
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ZIF0mUB__8eU for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 06:40:19 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC8C1AD255 for <tls@ietf.org>; Thu, 30 Oct 2014 06:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414676420; x=1446212420; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UHp5y2sZh/eKSiesicq81d/WKaYYI/YaF56Yea8m5BE=; b=DriO7Foc+ZaHX44wPOO6qsASbcfCSdGq8iQxAhHLkX3LQePi2ZC3gKtc vIZYw8h6mNgE7ib3nH3eAHmRs/gFudvOyv1oXSE6g0phlal0gZGTtvEOI Voe0RPJReg02UuZVvWKwjQ7tjU6j3zdi9WtNwTrM3vVbnFiDXjS5ksHGr I=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286681356"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 02:40:14 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 02:40:12 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/0RwccXPTVUB6lQEmHOtzHHp8uqg==
Date: Thu, 30 Oct 2014 13:40:11 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DC0AA@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3NOHlIUShLo9AAzXx4t2u7QV8Sw
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: Thu, 30 Oct 2014 13:40:21 -0000

Manuel Pégourié-Gonnard <mpg@polarssl.org> writes:

>Are you refering the "normal" (MtE) case or the EtM case here? 

The EtM case.  In the MtE case what gets MAC'd is the plaintext, i.e. only
TLSCompressed.fragment.  In the EtM case what gets MAC'd is the ciphertext
including padding and other stuff, so GenericBlockCipher.fragment.

>This is supported by the fact that both (what get's MAC'd and what goes in
>the wire) are written as TLSCiphertext.length in the RFC.

The correct notation to use is quite confusing, intuitively you can say "the
length used in the MAC calculation is the length of the data that gets MAC'd",
but specifying it in notation isn't so easy, it's the length of the padded
encrypted TLSCompressed value as well as the length of the IV if TLS 1.1 or
newer is used.  If there's some clear way of saying that that, say, at least
three different people can agree on I'll use it.

>Again, I have no preference on which interpretation is chosen, as long as
>there remains only one arguably valid way to interpret the text.

Sure.

>   MAC(MAC_write_key, seq_num +
>       TLSCipherText.type +
>       TLSCipherText.version +
>       length of ENC(content + padding + padding_length) +
>       IV +
>       ENC(content + padding + padding_length));
>
>    where the length is encoded as two bytes in the usual way.

That's still not quite right though because it excludes the length of the IV
when it's present in TLS 1.1+ (see above).  The intent of using
TLSCipherText.length was to accommodate the different protocol-version-
dependent options.

What about defining it the other way round, instead of saying "the length used
is this and that and sometimes something else", say "the length value used for
the MAC computation is the length as encoded on the wire minus
SecurityParameters.mac_length, since the MAC value is not included in the MAC
computation"?  So perhaps:

  Note that the value of the 'uint16 length' field in the TLSCiphertext record
  differs from the length value used in the MAC calculation, since the
  TLSCiphertext record contains both the ciphtertext and the MAC, while the
  MAC calculation is performed only over the ciphertext.  So the length value
  encoded in the TLSCiphertext record is 'length' while the length value used
  in the MAC calculation is 'length - SecurityParameters.mac_length'.

Peter.