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

Yoav Nir <> Tue, 10 June 2014 07:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 146201A0422; Tue, 10 Jun 2014 00:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u-Gzz46CkGCU; Tue, 10 Jun 2014 00:43:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C13FD1A0424; Tue, 10 Jun 2014 00:43:49 -0700 (PDT)
Received: by with SMTP id u56so2547546wes.35 for <multiple recipients>; Tue, 10 Jun 2014 00:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U1nIhWGrI4FR57IsTtBUTLElzNVqOpt/pL+TsFurS18=; b=FUgLSiOf/ilyTynEAbP5L2QRn0iw7c1kkD5HdKvmoDhDYRKqpAmYLpHJOHS0j3GKbM xVo8kbTb7TaVmDLT7itolkE+22pgZZ/zv/0IJFxHZM6dfnJqOq2zbuqcduVD4RMUVgrG mW6TYcJvaJYuB4dbBf7Ejx4AmzjtpxqEln3WTpmRF/SAiV8qjTGvNJe+XUvK5UU6rSVt Y6XfNapPGC3YZHQx76d3DI1s5zkt3a0GycrqdkwhiJE0L2esR164/hD6iwRH+XHcQ7HZ kedr5BXDv05VYZV8Ut9gPAKLWD/ZnAmbcYe64OZMlXmFfYycSx9OLdXrhxS+6s0KEhVD Vv/Q==
X-Received: by with SMTP id f11mr26648702wik.59.1402386228088; Tue, 10 Jun 2014 00:43:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id cy4sm19117174wib.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 00:43:47 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Tue, 10 Jun 2014 10:43:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "ietf\\" <>,
X-Mailer: Apple Mail (2.1878.2)
Cc: TLS Mailing List <>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-encrypt-then-mac-02.txt> (Encrypt-then-MAC for TLS and DTLS) to Proposed Standard
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jun 2014 07:43:56 -0000

[adding draft address]

On Jun 7, 2014, at 4:15 PM, Yoav Nir <> 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 <> 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
>> mailing lists by 2014-06-20. Exceptionally, comments may be
>> sent to 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
>> IESG discussion can be tracked via
>> 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