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

Juho Vähä-Herttua <> Fri, 29 November 2013 21:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28F131ADF27 for <>; Fri, 29 Nov 2013 13:42:53 -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 kgvJJJT_OJL7 for <>; Fri, 29 Nov 2013 13:42:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4C54C1ADA5D for <>; Fri, 29 Nov 2013 13:42:50 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTP id 35F41151690; Fri, 29 Nov 2013 23:42:38 +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 23:38:58 +0200
To: "" <>
Cc: "<>" <>, Nikos Mavrogiannopoulos <>, 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 21:42:53 -0000

> On 29.11.2013, at 22.17, (Martin Rex) wrote:
> I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> And the less code needs to be changed to adopt some useful feature,
> the more likely you will see it being adopted for patches/maintenance.
> I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> the GenericStreamCipher processing (which Peter's proposal does).

I'm trying to explain my reasoning. First of all HMACs are designed to authenticate data safely, but encrypting them adds an unknown factor to the calculation. Why not just use them as they are supposed to be used.

For me it is much more intuitive to do pad-encrypt-mac compared to attack resistant pad-mac-encrypt. In current TLS spec you can give the plaintext+HMAC to the encryptor as is and let it handle the padding. The same is true for encrypt-then-mac, just give the plaintext to the encryptor (either CBC or stream) and let it handle the padding. But in pad-mac-encrypt you have to know the length of the MAC before you actually calculate the MAC and add it manually! This is counter intuitive.

Finally, encrypt-then-mac allows detection of tampering in an earlier stage, which is a plus in my books.

> I also dislike (a) making a change to SSLv3/TLSv1.0 GenericBlockCipher
> processing, but (b) leaving the predictable IV exploited by BEAST
> unfixed, and essentially creating two seperate new GenericBlockCipher PDUs,
> rather than just a single one for all that fixes all known problems.

Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a very small update to TLSv1, so one could always ask why is it not supported better. Is the version number change somehow scary to people?

That being said, I would support adding explicit IV to the encrypt-then-mac spec, unless we have reason to think it would slow down adoption. Personally I don't see how a block of random numbers would be too difficult.

Nikos, do you think you should combine the pad and the IV in the defined structs? It would fix the BEAST attack at the same time even in SSLv3...

> The fact that GHASH must be encrypted is sufficient proof that an
> encrypted MAC provides a better safety margin than a plaintext MAC.

I don't think GHASH behaviour proves anything about HMACs, but please prove me wrong.

> MAC in the clear is only safe when the MAC algorithm is sufficiently
> close to perfect.  We know painfully well that our hash algorithms
> are *not* perfect, so I'm against taking chances, in particular
> for the GenericBlockCipher PDU.

But in a VERY hypothetical case where attacks to some HMAC is found, we would have no idea how it affects TLS without further analysis, using it in a standard way would at least give more information about what is broken. And of course HMAC is not just a hash.

>> Let's add an SCSV. How many SCSV hacks can we add?
> I think we should distinguish between "fixes" and "new features".
> Fixes should be as small as possible (code-wise and limited to the
> exact problem) so that they have a high chance of getting adopted
> for patches/maintenance to the installed base.

I kind of find this comment contradicting with the "we should fix all known issues (BEAST) in a single patch" comment. But I admit SCSVs are a necessary evil because of compatibility issues. It just makes me feel dirty...

>> 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.
> Partially true.  The footprint for AES-GCM code changes is so large
> that it may not happen for code that is under maintenance, rather
> than new products.  In particular,

Actually I wasn't talking about GCM which, as you say, is quite large.

>> Especially since CBC+HMAC AEAD ciphers that would be easiest to patch
>> are impossible in TLS because of the way AEAD is implemented.
> I'm sorry, I fail to follow.  CBC and AEAD seems to be two distinct
> modes of encryption and somewhat of a contradiction to each other.

I was thinking something like . It defines an AEAD CBC+HMAC mode which fixes all the known issues at once, as you suggested, but I find the padding outside of AEAD a bit of a hack. It is necessary only because we need to know the plaintext length in TLS AEAD interface _before_ decryption.

But getting people to accept an AEAD patch (just because it sounds scary if nothing else) is probably hard. I can understand why the chairs would like to go this "cleaner" route to fix CBC though.