Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

Juho Vähä-Herttua <> Fri, 29 November 2013 17:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 914271AE1BF for <>; Fri, 29 Nov 2013 09:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XSXii0AvbLCO for <>; Fri, 29 Nov 2013 09:05:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EEF121AE12E for <>; Fri, 29 Nov 2013 09:04:12 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTP id 719491397D3; Fri, 29 Nov 2013 19:04:02 +0200 (EET)
References: <>
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <>
Date: Fri, 29 Nov 2013 19:00:29 +0200
To: "" <>
Cc: "<>" <>, Peter Gutmann <>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Nov 2013 17:05:02 -0000

> On 29.11.2013, at 18.20, (Martin Rex) wrote:
> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
> strongly opposed to moving the HMAC into the clear, and into particular
> I am strongly opposed to put the HMAC into the clear for the
> GenericStreamCipher PDU.

You have been quite clear about that, and I've got the impression that you are the only but very vocal opponent of encrypt-then-mac on this list. Although in GenericStreamCipher it offers no benefit, I still haven't seen a convincing argument about why encrypt-then-mac should not be used.

I'm sure you have good reasons for this opposition, so could you please explain them in one or two sentences. This excluding the "encrypting the HMAC makes it safer" argument, which might be true but as I understand is not well proven.

> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

This might be the only way to solve this problem, but I must point out that SCSVs seem to be a solution for everything now. Browsers allow a version downgrade attack? Let's add an SCSV. The CBC handling is broken? Let's add an SCSV. How many SCSV hacks can we add?

Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hacks, but I'm worried it wouldn't be adopted fast enough. Especially since CBC+HMAC AEAD ciphers that would be easiest to patch are impossible in TLS because of the way AEAD is implemented.

So I prefer fixing CBC first (with encrypt-then-mac unless otherwise proven) and then allowing AEAD in all versions to let people prepare for GCM in whatever version they use instead of trying to force TLS 1.2 upgrade with GCM, it clearly isn't working.