IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 29 October 2014 15:30 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 8C2811A0217 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 08:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 eKRIvqce09QO for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 08:30:20 -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 599B71A01EC for <tls@ietf.org>; Wed, 29 Oct 2014 08:30:20 -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=1414596620; x=1446132620; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=nCqdD6xBOfrDWvu42pTT7w1KBaUWrauhR6u1sXvUj4A=; b=PqPOsMj4feI28GLAonbiC++hxKOTOez/NQlXqDHn8apm7QMt7CZwkfrp pjWt06UunS0d2xOA0crin7rpw4hC/Q4qqGcUwKxxv4D1FwUMlUZqnEROp yB/UiZ9Rgfn1NeJ2+5GSYtmqsaDEUhRFi5R+swkAX7TXgOw4MVL6Rw59l k=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286452748"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 04:30:18 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 04:30:18 +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/zjT4FRw5eOE5fRKuz5tvYgntzng==
Date: Wed, 29 Oct 2014 15:30:17 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB460@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/CPJVDkBc7J7M4eB0V1qNZ1fuYqk
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: Wed, 29 Oct 2014 15:30:22 -0000

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

>The *only* difference is (something that doesn't involve the definition of
>length), so the definition of the length is unchanged, therefore it's the one
>from RFC 5246.

No it isn't.  RFC 7366 moves the MAC outside the GenericXXXCipher fragment, so
it's no longer included.  In fact it doesn't even make any sense to include
the MAC length, if you tell your code to MAC the length of the ciphertext plus
the length of the MAC you'll end up MACing 20 or 32 bytes of whatever random
data happens to be present at the end of the ciphertext.  TLSCiphertext.length
is exactly that, the length of the ciphertext, which in RFC 7366 no longer
includes the MAC.  It's not "TLSCiphertext.length + some other data that's
present at the end of the ciphertext".  Even RFC 5246 supports this, it says:

  The encrypted data length (TLSCiphertext.length) [...]

The MAC is no longer encrypted, so it's not part of the encrypted data length.

Peter.

v2.23.0 | Report a Bug | By Email