Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:

Bodo Moeller <bmoeller@acm.org> Mon, 18 November 2013 17:09 UTC

Return-Path: <SRS0=lvm6=U3=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C741E11E817B for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 09:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level:
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDfDHTbuqMZo for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 09:09:15 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8837811E8190 for <tls@ietf.org>; Mon, 18 Nov 2013 09:08:25 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MbK2G-1W15ed1fm8-00J5iI; Mon, 18 Nov 2013 18:08:23 +0100
Received: by mail-ob0-f172.google.com with SMTP id gq1so2178657obb.17 for <tls@ietf.org>; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uKSQgRbOWui6SvaGcTab9vuPfNw8Q3YF+sSQDmvprEs=; b=bUnYQPxCjFiJkcRerYJG6tVwm6QoykMJSuoo1RjB81VQ5vapLRKlm9NKskS8xD2tPA AKw5FOciuv7M739lWU3jM73vv70TkseeDyRveRkALJmPv0pg3WsJRl1GAe/nHXK9oSgL s32nnLynjgP9FcALA1UYC6YEV+t3Z1Ylu4uj3J4N8W70vwkxiZSMG/GKi1vAPkmtHKrP g0oNydZkRjP5Yb4XwiieeEWyAxxU1hQvWlw84wwtfjiVmulOeXrWhjAXtD29Ptpag3q2 ZXHRPlYPlOSVRc5FdJOT0VoLiRKslyp+cphBKVWDxMHSemxL5263zH2GQQObLcD8TyOP QdiA==
MIME-Version: 1.0
X-Received: by 10.60.145.241 with SMTP id sx17mr1483634oeb.57.1384794502205; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
In-Reply-To: <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com> <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com> <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Mon, 18 Nov 2013 18:08:22 +0100
Message-ID: <CADMpkcKWNEw-LaMG7dXS50S0Gikxa5HnYp2m-O5o_fJKXSOk9Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Marsh Ray <maray@microsoft.com>
Content-Type: multipart/alternative; boundary=047d7b5d474a641bbc04eb769889
X-Provags-ID: V02:K0:4rIPGnb3/ve2kRdyQdG/Yf4BiLYLPkFZsiuXnR/j7r0 SQm4uQf7CQ1UQl9mjoTz83nz2jKqpxpp/80bRZ9BVPoUpq7Q+s ldrYyO79bkzs7mJuZnKSKPJtTBoH6XwuD9/XQVfuTnzlPNwWB/ MmOQ1Fu8DM510zR1z7MEws24lZ/ymJDVyxDCNohIn+uJFcZYD4 xnbYcF31mdfahUIyt0ArOHnh0l3KgSIlY/jD+CCJLid4mg1rky lgVRLTNTTVKq+bzJkRjXO8WhgjaCgxyrneU+Udtrnp59D7FhpK obUGTC1oGAvbjse39Q3fkqYAFIIfk5JolIyZFzqPVejw6jsaei aS8Q0xq3kUb8CE4xRHk8O335fcyh6YKeCpA86kYTaOUZPU2In0 CSx6++z8AeyRNt66T4WcGqjIULjz2S0P0Ot1nlbpGLcSN/CuoC dItSM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 18 Nov 2013 17:12:41 -0000

>
> Yeah, I didn't mean to imply so much that HMAC is the One True MAC or that
> integrated AE modes can never be defensible. Just that
> MAC-(then|and)-Encrypt are broken while Encrypt-then-HMAC is a very
> conservative design which has stood the test of time and emerged victorious.



 See: https://twitter.com/elwoz/status/401135814307889152
> Figure 2 from http://eprint.iacr.org/2000/025
>
>
While you are right, http://eprint.iacr.org/2000/025 alone isn't why MtE is
broken (and https://twitter.com/marshray/status/401147046767239169/photo/1thus
is a gross over-simplification -- not that there's anything wrong with
that, per se ...).

That Bellare/Namprempre paper did show that MtE is not *generically*
secure.  However, there's also http://eprint.iacr.org/2001/045 =
http://www.iacr.org/archive/crypto2001/21390309.pdf, showing (sort of) that
MtE *is* secure if E specifically is, for example, CBC encryption.  Well,
we all know how well *that* went [*][**] ... but the various problems with
CBC ciphersuites are not implied by the Bellare/Namprempre paper.

[*] See Paterson/Watson, "Authenticated-Encryption with Padding: A Formal
Security Treatment", 2011, for a more complete truth.  That article is
behind a paywall, but Kenny conveniently provided this pointer to Gaven's
thesis: http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf

[**] I must have my hand-written slides somewhere ...
http://www.iacr.org/conferences/crypto2002/rump-prog.html

Bodo