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.
- [TLS] rfc7366: is encrypt-then-mac implemented? Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Ilari Liusvaara
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Henrick Hellström
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Peter Gutmann
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- [TLS] record-level version number in ClientHello Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Yngve N. Pettersen
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Christian Kahlo
- Re: [TLS] record-level version number in ClientHe… Martin Thomson
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Martin Rex
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Manuel Pégourié-Gonnard
- Re: [TLS] rfc7366: is encrypt-then-mac implemente… Nikos Mavrogiannopoulos
- [TLS] rfc7366: status Nikos Mavrogiannopoulos
- Re: [TLS] rfc7366: status Martin Rex