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

Robert Ransom <rransom.8774@gmail.com> Fri, 29 November 2013 17:26 UTC

Return-Path: <rransom.8774@gmail.com>
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 7A11B1ACC8A for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 nCiG2pc-SRbx for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:26:08 -0800 (PST)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2531A1AC43E for <tls@ietf.org>; Fri, 29 Nov 2013 09:26:08 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id nd7so9961127qeb.17 for <tls@ietf.org>; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C8Gn74K1aj2e5xotzFseYp95Ro10QQ3nSi7US8RefcI=; b=VK77TIiQIZI2+i+0P5tOKtTFWRK79fNNpWHHbwg3kInN/Wuj8X/9Wd+VVjjroYjm9D 88GB4yxbBb21IjcZh82tQ9CSbAyqv7Xop8kg9AaM7yvgd09kVGqKqdjc35f1Qufur/Ih fvFYzqKrV+rbvQUViVCcdgZc89OayimXgJ39sinqQz24vVWeQ4ljXwR74SSlSvUxi+qb qFk/wnEvaXSI+T/PHI3cq7E1ZJtsHFwoqG1v9bj6Ns7JZt05t8vP+WGiZwVCtJb1TNUl 4nSZjERF1AwK3kfGhQVc/dhGqn7U2TcFtPXYBjNQC39Dju+xeHCCS30phpLM5+CMyWrv Yo/Q==
MIME-Version: 1.0
X-Received: by 10.49.94.177 with SMTP id dd17mr88542465qeb.14.1385745966780; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
In-Reply-To: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
Date: Fri, 29 Nov 2013 09:26:06 -0800
Message-ID: <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= <juhovh@iki.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Fri, 29 Nov 2013 17:26:09 -0000

On 11/29/13, Juho Vähä-Herttua <juhovh@iki.fi> wrote:
>
>> On 29.11.2013, at 18.20, mrex@sap.com (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.

Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
don't know of any others.

> 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.

"not well proven" is the wrong phrase here.  Marsh Ray solidly debunked it.



> 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.

To put it even more bluntly: OS and hardware vendors will treat TLS
1.2 or AEAD support and an efficient-in-secure-software AEAD cipher as
new features, and sit on them for a few *years*.  TLS, and every
pre-1.2 TLS implementation in the world, needs a critical security
bugfix *yesterday*, and the only bugfix I see that is ready to be
deployed as such is draft-gutmann-tls-encrypt-then-mac.


Robert Ransom