IETF Logo Mail Archive

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

Manuel Pégourié-Gonnard <mpg@polarssl.org> Wed, 29 October 2014 13:59 UTC

Return-Path: <mpg@polarssl.org>
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 6933F1A0107 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 06:59:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.397
X-Spam-Level: *
X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 1LBEahTYnEhr for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 06:59:16 -0700 (PDT)
Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FDE1A00F9 for <tls@ietf.org>; Wed, 29 Oct 2014 06:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=fR2ur+lLKvi0d+34c7tlqjEDgyALguBfkccj8FnhIG8=; b=dWz72HdVxdASlonAmSVg1jOpwXuTqng8eGdgH1YrFd4Y8Dsd4xPG4t/oG7n5fjzV5r8L09uTnw8rtfgg0eVl+kmwgDKcUWkY58af1WgFaRKCSZ2cn8Pj5a/ucjCLHUwb2aJSCurLAtT+28ZaUK1H/CynQPKkYGTpdZWPafhU5Jo=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1XjTmF-0001Q5-PC; Wed, 29 Oct 2014 14:59:08 +0100
Message-ID: <5450F2B0.9000800@polarssl.org>
Date: Wed, 29 Oct 2014 14:59:12 +0100
From: Manuel Pégourié-Gonnard <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>, Christian Kahlo <christian.kahlo@ageto.net>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DB261@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NI9QuoG2_qz7NP9-H1jT0BYwA5c
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 13:59:19 -0000

On 29/10/2014 14:21, Peter Gutmann wrote:
> Manuel Pégourié-Gonnard <mpg@polarssl.org> writes:
> 
>> My implementation does not interoperate with the one at eid.wx4.net either,
>> when I enable EtM (fails with a bad_record_mac alert).
> 
> So what are people doing to get this?

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.

I strongly agree with Nikos that an erratum should make this explicit if that
was the intention of the document. (Or if this was not the original intention
but you prefer to align on the implementation(s) already deployed to avoid an
interop nightmare.)

Manuel.

v2.23.0 | Report a Bug | By Email