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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 15 November 2013 15:24 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 B123B11E81A2 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 07:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 cAGSbJRXG6lQ for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 07:24:23 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EA5F321F9A5F for <tls@ietf.org>; Fri, 15 Nov 2013 07:24:22 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id ec20so2856385lab.38 for <tls@ietf.org>; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fkwXNjNOSzqYENLN2/VT1+v+WB5cHRaNUGSyD7bZgX0=; b=bv3Tpg5KK5V1MpoVyo4Lll8v0reSCe0gnEq42Yf3u1AeUFfCqE2FNK4mfjXEh4XeYg K4hHXu2lU0uMovA+pOOVwYdED23CU3IdFYV9ct/9uxxn2yCZs7FlJQ/Z7eqoFnthCxJS of/NOwqEjM88i3xR84kDqlRmmdyXy+SwftPawhlNJgUUDiVZMYCbhvDrLN7dqdcuFBx/ VlrUj6Ep+tet+2ydKk8lANFI7twFg496OfK9jL0yaoUF+KTEC5AlmFqirVldlrdEkC1x z8TqXGvonsjr1O81vGouNfpCsLbtbFPz1lXqg4PE64Ab7MYp1n+cD/qjEC/pNnRFZnL4 R6eQ==
MIME-Version: 1.0
X-Received: by 10.152.3.42 with SMTP id 10mr4708007laz.22.1384529061838; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
In-Reply-To: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Fri, 15 Nov 2013 16:24:21 +0100
X-Google-Sender-Auth: QZ2gobM56T5lY3VTq8Mb95qzlJY
Message-ID: <CAJU7zaK237JJPageTC+HRzLvmvi-1yEaS08VG_zCDpmMH_YwuA@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 15 Nov 2013 15:24:23 -0000

On Thu, Nov 14, 2013 at 10:00 PM, Marsh Ray <maray@microsoft.com> wrote:
>
>
> Our knowledge of generic hashing constructions has evolved:
[...]
> My conclusion is that for any reasonable choice of hash function, the TLS
> PRF is noninvertible. To put this another way, if this feat were
> demonstrated even using the horribly broken MD5 it would be earth-shattering
> in its crypto impact. It is secure forever, unless there are seriously
> fundamental advances in complexity-theoretic cryptanalysis. And if that day
> comes, *it will be your fast ciphers that you’ll worry about*. The TLS PRF
> is by far the slowest, most conservatively designed stream cipher in common
> use.

Hello,
 These are interesting facts and I don't think anyone denied them in
this list. The fact however that EtA is ok, doesn't imply that AtE is
not ok. The only stream cipher in TLS had never issues due to the mode
of encryption (AtE). Why switch it to EtA when we know the issue and
can fix (fix and not hack) the currently used mode?

In any case that is argumentation for the sake of argumentation. Now
we are full of hacks solving the issue and what we need is some action
on this topic.

regards,
Nikos