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

Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 10 June 2014 15:02 UTC

Return-Path: <hugokraw@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 7958E1A01AB; Tue, 10 Jun 2014 08:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 w3ND-kq8BfvE; Tue, 10 Jun 2014 08:02:04 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3151B27DF; Tue, 10 Jun 2014 08:02:04 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id j5so502710qaq.40 for <multiple recipients>; Tue, 10 Jun 2014 08:02:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qMi+UPnYOSUMQROXc2H3z23kJykyHOPsViVKmMeSMsk=; b=syPkiklYLunINr73tHX0ZjwICtG1DD5fArk8ZsuxyjDGUphe65CB/dwf+ThIiZfJMx qfAc9p3sUuk+NLN82C3zUyHhWJvJ60v98fBc/XEg5ELy0SxhYO+29yQiTRb2P0zuUzw3 bn/cCXphi0XyH6QPg7FzmP6N+uK5Xx7JbCNREbCMXhjOx0ikwiU6ibUcCPDru1sFkWNI W/u3Pr8uaO9g/7KqC8PT05JusQ6izJ8BtrPVwwM3cuSVU8WNnq5YMrRz/ToOLTHRDN8j FvH8GJvbgQkeORDCvo7i04CeF9aO8tEznqULaPvUhkWrOHMnbn9ee8B0QuHup4HIa4zX kH/Q==
X-Received: by 10.140.48.1 with SMTP id n1mr13696772qga.107.1402412523157; Tue, 10 Jun 2014 08:02:03 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.96.83.106 with HTTP; Tue, 10 Jun 2014 08:01:32 -0700 (PDT)
In-Reply-To: <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com>
References: <20140606145220.8187.67355.idtracker@ietfa.amsl.com> <36137A9A-3503-4AF8-80D0-1FB53A7949EA@gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Tue, 10 Jun 2014 11:01:32 -0400
X-Google-Sender-Auth: UgyLiWocyaQ8Cvms9qXhc7IGS_A
Message-ID: <CADi0yUN+A7QGZLeSDDXMLhK6mr4O09rGr0ZJy6AafPVSQJX1tA@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a11350eac458a1f04fb7c9c02
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gSrJQm7UdSiVaP0EZ5oagXRC8ao
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 15:02:06 -0000

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




On Sat, Jun 7, 2014 at 9:15 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> Hi
>
> I’ve read the draft and I have a  few comments:
>
> The motivation for this extension is not clear from the draft. The
> introduction says that the MAC-then-encrypt construction is “no longer
> regarded as secure”, and that it has been the subject of “numerous security
> vulnerabilities and attacks”. For the latter claim, there are no references
> given either in the document itself or in references. For the former two
> articles are cited.
> The first (reference [5]) is by Hugo Krawczyk. While that article shows a
> theoretical weakness of MAC-then-encrypt, it also finds that (quoting from
> the abstract) “On the positive side we show that the
> authenticate-then-encrypt method is secure if the encryption method in use
> is either CBC mode (with an underlying secure block cipher) or a stream
> cipher (that xor the data with a random or pseudorandom pad).”. It also
> concludes that “the current practical implementations of [SSL] that use the
> above modes of encryption are safe”. So this is not a great call for action.
> The second (reference [6]) is a better reference, but I’m still missing a
> reference to anything practical or close to practical.
>
> The rationale for the mandate in section 3.1 is not clear to me. Sure, EtM
> is better than MtE, so renegotiating from MtE to EtM is a downgrade, but
> there is no mandate for implementations that are configured to support both
> algorithms to avoid downgrading from AES-256 to single DES, so why add this
> here?   Also, this section uses the terms “state”, “status” and “mechanism”
> seemingly interchangeably, and doesn’t explain why changing mechanism
> during renegotiation is a SHOULD NOT-level issue, or how AEAD ciphers
> figure in this mandate.
>
> One more thing, this time a nit: informative reference number 7 describes
> a document as “RFC xxxx”. This is a reference to
> “draft-bmoeller-tls-downgrade-scsv”, which according to the datatracker is
> an individual draft that nobody’s asked to publish yet. It should be
> referenced with the draft name as a work in progress. Since it’s an
> informative reference, this won’t block publication of this document.
>
> Yoav
>
> On Jun 6, 2014, at 5:52 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> >
> > The IESG has received a request from the Transport Layer Security WG
> > (tls) to consider the following document:
> > - 'Encrypt-then-MAC for TLS and DTLS'
> >  <draft-ietf-tls-encrypt-then-mac-02.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2014-06-20. Exceptionally, comments may
> be
> > sent to iesg@ietf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >   This document describes a means of negotiating the use of the
> >   encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing
> >   MAC-then-encrypt one, which has been the subject of a number of
> >   security vulnerabilities over a period of many years.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> > ID nits found an Obsolete normative reference: "RFC 4366 (ref. '3')
> > (Obsoleted by RFC 5246, RFC 6066)" which will be replaced.
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>