IETF Logo Mail Archive

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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 30 October 2014 11:12 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 373DF1AD0B8 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 04:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 TqQYTKc1nVx9 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 04:12:13 -0700 (PDT)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFCF1AD09D for <tls@ietf.org>; Thu, 30 Oct 2014 04:12:13 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8705E8187B; Thu, 30 Oct 2014 13:12:10 +0200 (EET)
Date: Thu, 30 Oct 2014 13:12:10 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Message-ID: <20141030111210.GA15345@LK-Perkele-VII>
References: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9DBED9@uxcn10-5.UoA.auckland.ac.nz>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BQBFelIsMhBYQMA3iHS0LKhn9nI
Cc: "<tls@ietf.org>" <tls@ietf.org>
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 11:12:16 -0000

On Thu, Oct 30, 2014 at 09:40:24AM +0000, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos <nmav@redhat.com> writes:
> 
> >So is my understanding correct that no deployed implementation is compliant
> >to rfc7366 so far?
> 
> Now that it's an RFC, a new set of implementers have managed to come up with
> an interpretation that, AFAICT (a) isn't in the RFC, and (b) doesn't make any
> sense.  I could certainly issue a clarification, but first I'd have to
> understand (a) how recent implementers are managing to come up with an
> interpretation that isn't in the RFC and (b) what sort of wording to use to
> correct this.

I read relevant parts of RFC7366 and RFC5246. 

I got (perhaps weird) interpretation that this extension truly pulls the
MAC off ciphertext fragment.

Thus, the length field on _wire_ does _not_ include the MAC, and the
MAC'd data is what is on wire, bit for bit.


E.g. 14-byte application payload, minimal padding, AES-CBC, HMAC-SHA1,
TLS v1.2: 32 bytes, regardless of MAC truncation (whereas normally it
would be 52 for full and e.g. 48 for 16-byte truncated MAC).


What that sort of thing does to "middleboxes" that for some reason
parse the TLS PDU stream could be somewhat... interesting.


-Ilari

v2.23.0 | Report a Bug | By Email