Re: [TLS] Last Call: <draft-ietf-tls-encrypt-then-mac-02.txt> (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard

Yoav Nir <ynir.ietf@gmail.com> Tue, 10 June 2014 19:59 UTC

Return-Path: <ynir.ietf@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 86F5D1A0332; Tue, 10 Jun 2014 12:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 oI-LS20CL9bU; Tue, 10 Jun 2014 12:59:39 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD3A1A02D0; Tue, 10 Jun 2014 12:59:38 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id b13so3141283wgh.11 for <multiple recipients>; Tue, 10 Jun 2014 12:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7CReMo8ryZyMUI0fhbyfXjBIF3PAEYIRz3f30gGCuJI=; b=Czve1MmkGyAUgKzqxu51it/hbnVepVWHcWCvAtZnU0CxZr19KF+rb/bNZHpF3EVGNx zt9nDK5rsNle7pYEvW3v/W9e1/30E+YqyKAPH7sZ93XwOJB6V8cO+JbfZlqDIZhlIPSv sO8VXjptn+6wvc/59aQvfzsy4Fr1cX58QJzzY646E0eTWYvegchamz7oDwJaVrztoIK9 1YRwcdNkpBZKSrOqeStPchm9OVQT747euPeFsyd45V4YzIV91PVr/dW3E80OS3t0Bebq 0Xv1gE/vsY4qSo5MF+/qVnZxWqepIkbQ42zk0U95onNtN2gnMwqoZ5DoqkvwbLgDmCd+ 42tQ==
X-Received: by 10.194.175.106 with SMTP id bz10mr7342333wjc.96.1402430377180; Tue, 10 Jun 2014 12:59:37 -0700 (PDT)
Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id ey16sm1915527wid.14.2014.06.10.12.59.35 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 12:59:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_745AF1FA-2345-468C-B408-26F610CF7747"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CADi0yUN+A7QGZLeSDDXMLhK6mr4O09rGr0ZJy6AafPVSQJX1tA@mail.gmail.com>
Date: Tue, 10 Jun 2014 22:59:32 +0300
Message-Id: <7E22B933-C3EE-4F58-873D-88FEE7C9778F@gmail.com>
References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com> <CADi0yUN+A7QGZLeSDDXMLhK6mr4O09rGr0ZJy6AafPVSQJX1tA@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MegIVROmgHqqBORy1OHWYb41Cr4
Cc: "ietf\\@ietf.org" <ietf@ietf.org>, TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-encrypt-then-mac-02.txt> (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard
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: Tue, 10 Jun 2014 19:59:40 -0000

On Jun 10, 2014, at 6:01 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:

> The technical results in my 2001 paper are correct but the conclusion regarding SSL/TLS is wrong. I assumed that TLS was using fresh IVs and that the MAC was computed on the encoded plaintext, i.e. Encode-Mac-Encrypt while TLS is doing Mac-Encode-Encrypt which is exactly what my theoretical example shows is insecure. The later padding attacks showed that the theoretical example of insecurity had a very practical instantiation in TLS.  While the paper shows correctly that MAC-then-Encrypt can be secure with both CBC and stream ciphers, it also shows that it requires a LOT of care about encoding - it turned out that TLS/SSL was not doing that. So if you want to keep Mac-then-Encrypt then you must change the encoding as well as how you apply the MAC. Changing to Encrypt-then-MAC is a much safer solution.
> 
> Hugo

Thanks

Yoav