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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 29 October 2014 14:32 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 F35B91A0121 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 07:32:37 -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 zpGwpTzdKyy3 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 07:32:34 -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 8167C1A0162 for <tls@ietf.org>; Wed, 29 Oct 2014 07:32:33 -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=1414593155; x=1446129155; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=F5nqkMeOjOxbNRTeI/wP0+bUXqfmt2XwANZpidg/KOM=; b=ulBiV3HGXxDwINcVQy6PiYfwATZZZOI2peMQ/nx4nFJn1aHjGYx3NhaY JoDEQgTBYozqJqW++uvr0Ed4TMhs/bhBfV/HN37FBoCwDExudaganH437 aubsdPqQEj1BIV4igdMd38F0F7m+xSSd8+zHaKOZ4FEEHe9Ky7Gwvt9Ir s=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286449134"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 03:32:33 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 03:32:31 +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/zhSuMnPT4sluYS4uIZ4wfXRYS+A==
Date: Wed, 29 Oct 2014 14:32:30 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB32F@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yvAtLORC2FSxX4rgUe52ybvELD8
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 14:32:38 -0000

Nikos Mavrogiannopoulos <nmav@redhat.com> writes:

>I believe the description of Manuel and the NSS one [0] are pretty clear. If
>that bunch of implementations interoperates with eid.wx4.net then they don't
>follow the text in rfc7366.

I'm still not clear how NSS interprets this in the way it does.
TLSCipherText.length is the length of ENC(content + padding + padding_length),
which from section 6.2.3 of RFC 5246 is now the same as TLSCipherText.fragment
(since the MAC isn't part of GenericWhateverCipher any more).  So whether you
pass in TLSCipherText.length (as per the RFC) or TLSCipherText.fragment (as
NSS does) shouldn't make any difference because they're the same thing.

Peter.