Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

mrex@sap.com (Martin Rex) Fri, 29 November 2013 20:17 UTC

Return-Path: <mrex@sap.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 5B6371ADDAC for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.052
X-Spam-Level:
X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 jXgUW2eqbu8l for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:17:28 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5C071ADBCA for <tls@ietf.org>; Fri, 29 Nov 2013 12:17:27 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rATKHElw014512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 21:17:14 +0100 (MET)
In-Reply-To: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
To: =?UTF-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Fri, 29 Nov 2013 21:17:14 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 29 Nov 2013 20:17:30 -0000

Juho Vähä-Herttua wrote:
>> 
>> On 29.11.2013, at 18.20, mrex@sap.com (Martin Rex) wrote:
>> 
>> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
>> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
>> strongly opposed to moving the HMAC into the clear, and into particular
>> I am strongly opposed to put the HMAC into the clear for the
>> GenericStreamCipher PDU.
> 
> You have been quite clear about that, and I've got the impression that
> you are the only but very vocal opponent of encrypt-then-mac on this list.
> Although in GenericStreamCipher it offers no benefit, I still haven't
> seen a convincing argument about why encrypt-then-mac should not be used.

I'm from the "don't-fix-it-if-it-ain't-broken" camp.
And the less code needs to be changed to adopt some useful feature,
the more likely you will see it being adopted for patches/maintenance.
I have seen *ZERO* compelling reason for switching to encrypt-then-mac
in TLS.  And I'm not aware of *ANY* reason why we should touch/change
the GenericStreamCipher processing (which Peter's proposal does).

I also dislike (a) making a change to SSLv3/TLSv1.0 GenericBlockCipher
processing, but (b) leaving the predictable IV exploited by BEAST
unfixed, and essentially creating two seperate new GenericBlockCipher PDUs,
rather than just a single one for all that fixes all known problems.


> 
> I'm sure you have good reasons for this opposition, so could you please
> explain them in one or two sentences. This excluding the "encrypting the
> HMAC makes it safer" argument, which might be true but as I understand
> is not well proven.

The fact that GHASH must be encrypted is sufficient proof that an
encrypted MAC provides a better safety margin than a plaintext MAC.

MAC in the clear is only safe when the MAC algorithm is sufficiently
close to perfect.  We know painfully well that our hash algorithms
are *not* perfect, so I'm against taking chances, in particular
for the GenericBlockCipher PDU.


> 
> > Signaling of this PDU change will be through a new SCSV in ClientHello,
> > confirmation by the Server through a simple ServerHelloExtension, similar
> > to how signaling is done for rfc5746 (TLS renegotiation_info extension).
> 
> This might be the only way to solve this problem, but I must point out
> that SCSVs seem to be a solution for everything now. Browsers allow a
> version downgrade attack? Let's add an SCSV. The CBC handling is broken?
> Let's add an SCSV. How many SCSV hacks can we add?

I think we should distinguish between "fixes" and "new features".
Fixes should be as small as possible (code-wise and limited to the
exact problem) so that they have a high chance of getting adopted
for patches/maintenance to the installed base.

Looking at how many new ciphersuites have been proposed over the years,
the number of SCSV proposals IMO pale in comparison.  Even the "silly
ciphersuites" in rfc5246 outnumber the current SCSVs:

(ciphersuites which, according to SP800-57 are non-sensical)

rfc5246:
      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,0x3C };
      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,0x3E };
      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,0x3F };
      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,0x40 };
      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,0x67 };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };

According to SP800-57, HMAC-SHA1 is perfectly sufficient for combination
with AES128, and this is even more true for encrypted HMAC-SHA1 with
TLS'es GenericBlockCipher PDU.

(btw. the one thing that confuses me about
 NIST SP 800-57 Part1 Rev.3 (July 2012) is that GHASH does not
 appear in Table 3 on page 65.)


> 
> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require
> hacks, but I'm worried it wouldn't be adopted fast enough.

Partially true.  The footprint for AES-GCM code changes is so large
that it may not happen for code that is under maintenance, rather
than new products.  In particular, AES-GCM will probably require
FIPS 140-2 recertification, whereas a fixing the CBC padding may
not need a recertification (this probably depends on the software
module boundaries).


>
> Especially since CBC+HMAC AEAD ciphers that would be easiest to patch
> are impossible in TLS because of the way AEAD is implemented.

I'm sorry, I fail to follow.  CBC and AEAD seems to be two distinct
modes of encryption and somewhat of a contradiction to each other.

Were you thinking of AES in counter mode with HMAC as MAC?
AFAIK, this could be done with GenericStreamCipher instead.

> 
> So I prefer fixing CBC first (with encrypt-then-mac unless otherwise
> proven) and then allowing AEAD in all versions to let people prepare
> for GCM in whatever version they use instead of trying to force
> TLS 1.2 upgrade with GCM, it clearly isn't working.

Personally, I trust CBC+HMAC more than I trust GCM.
I have difficulties thinking of weaknesses of the cipher, that when
found, would always affect both CBC and GCM modes.  But not all weaknesses
that are fatal to GCM would also be fatal for CBC.

And we know that our algorithms are not perfect, and that NIST
didn't put much of a security margin into AES -- so little that
AES-256 is known to fall quite short of 256-bit security.


-Martin