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

Alfredo Pironti <> Sat, 30 November 2013 18:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 96F441AE141 for <>; Sat, 30 Nov 2013 10:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dNT8iVf1T66Y for <>; Sat, 30 Nov 2013 10:23:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::231]) by (Postfix) with ESMTP id 720391AE136 for <>; Sat, 30 Nov 2013 10:23:55 -0800 (PST)
Received: by with SMTP id i4so11435096oah.22 for <>; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fYFAz/5aHcBzBEAFB16WBMgb5aFSo0zbflsEe9ixB6Q=; b=a4usZSwWrya2uNbVA8lQqXBUpXlZvicv+B+B2xxO9ZJcz6BYCINnkdpcW+eL7OjbHa m2x3wrZcw8NFtkrbeLDQD5b8oH9MK5GcxJFZdv6kzD7oqQMddcz7TqQmbVW8Tf1FGmII tZndXxD9MnGwsry02bMoYA+Zyx/fhPtjcIrsU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fYFAz/5aHcBzBEAFB16WBMgb5aFSo0zbflsEe9ixB6Q=; b=Pd+EEosEf1CE/4EhNAnrxHsELwzYQyvQv71m9vAWNPH1aOcT9npAiP4hq0EyuGzuiy MaFxi/kkPbMoUF+aHqAyUdKkUzqyQ9oBpoF4ZmPbIhtQ8sFTv16/2NBfbKknrlYFtEl9 jnr6iQYqYVlvcs+0c6Wp0ErF5Ot60WqQulWYwVvQEfkIWJSglsrAuFWXGnEpmyvDcFed vb79jmJjK20nyP+WtoOXBYrbij6kNggdMcJc6OB0qGS+/gwy0+urTGKC1IAXQb89hhpg w9sMkfYu49gLvm258pkXGBlo8M3IXw7jXzXfMKVrd9fbsJOH9CG/Gi6U5llrnAkqVZvI PEQw==
X-Gm-Message-State: ALoCoQn1iZPyuTi4ujUvON28jSBbz6XPOjwnKU3MvDXuTdseKjfshBtbhQmpxWsYLm+u6LWd/1S8
MIME-Version: 1.0
X-Received: by with SMTP id u8mr381521oer.54.1385835833736; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
Received: by with HTTP; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <1385826600.11639.25.camel@aspire.lan> <> <> <>
Date: Sat, 30 Nov 2013 19:23:53 +0100
Message-ID: <>
From: Alfredo Pironti <>
To: Watson Ladd <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
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: Sat, 30 Nov 2013 18:23:56 -0000

On Sat, Nov 30, 2013 at 7:02 PM, Watson Ladd <> wrote:
> On Sat, Nov 30, 2013 at 9:58 AM, Alfredo Pironti <> wrote:
>> Hi Kenny,
>>> But, at the risk of repeating myself, I very much prefer the simplicity
>>> and robustness of an Encrypt-then-MAC construction.
>> I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
>> the only two cipher modes I'd like to see in TLS 1.3.
> You do realize EtM is an AEAD if properly designed?

I do. I was just speaking in TLS1.2 terminology, which does make a
distinction, even though all schemes are supposed to deliver
Authenticated Encryption with Additional Data anyway. If I just said
that I only wanted AEAD, somebody else would have shoot at me instead
by saying that GCM is too inefficient.

>> In practice however, we witness the disastrous experience in widely
>> deploying any change which is not a small patch to TLS1.0. So I'm
>> afraid that to get something deployed in reasonable times we may have
>> to get content with such a patch, like pad-MAC-Encrypt, that makes
>> more robust (if not provably secure) what we already have.
> How is pad-MAC-Encrypt less of a change then Encrypt then MAC?

It is easier enough in that 2 implementations already implement pad-MtE
(GnuTLS and miTLS), and my personal experience in implementing the
patch says it's a small change.

But we need even more factual feedback, and I hope we get more people
to try to implement it elsewhere.

> We still can't kill RC4, which is a *configuration change*.
> Patches aren't getting deployed even if painless, so arguing about the
> ease of deployment is a red herring.
>> Alfredo
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin