Re: [TLS] padding bug

Hugo Krawczyk <hugo@ee.technion.ac.il> Tue, 24 September 2013 18:18 UTC

Return-Path: <hugokraw@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 1978921F9F5B for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 11:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.226
X-Spam-Level:
X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_OBFU_ALL=0.751]
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 QbKbyK-UtcO1 for <tls@ietfa.amsl.com>; Tue, 24 Sep 2013 11:18:12 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E802A21F9F31 for <tls@ietf.org>; Tue, 24 Sep 2013 11:18:11 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id uz6so5406019obc.33 for <tls@ietf.org>; Tue, 24 Sep 2013 11:18:11 -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=LNj2qj5bOn6/crmVt5nluZJNkp5+g8UnTgszUvVlkps=; b=lidL9UQ8mimVKyQsW8B8qetXKiw94FRNaQ932UdXiMY1CFyHlll2CCdOBG4KKio8Nz F4Tedv2UmoRRLwk62Jmqawg+6eRp41gUUjNKD3WA5iEsqXhg/AWgG8CjHvNWwgu9kgkU 9y2wp0sBp94RKZ4/xsAkLKxLZauyOuXzZc2NjQcU8JCCj0IPnGxYwZNnaLGk6I0ElFY3 mwkQyB4oI6IwgBlNM4aJlGX+GvyK+H3LL7umClAzDPAsaZGWzVGi8daOYGs8HiIEfwAT 6y8cPEECyF+1O9J206+2y7rfuBUsHliagtSQt0NF/GKJHk2ViV4VG22aNVvBfK28BqIV 3tnA==
X-Received: by 10.60.134.14 with SMTP id pg14mr2452360oeb.66.1380046691148; Tue, 24 Sep 2013 11:18:11 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.182.204.34 with HTTP; Tue, 24 Sep 2013 11:17:41 -0700 (PDT)
In-Reply-To: <20130924124848.450EC11E8121@ietfa.amsl.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz> <20130924124848.450EC11E8121@ietfa.amsl.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Tue, 24 Sep 2013 14:17:41 -0400
X-Google-Sender-Auth: efqdwPo8UzkVo1cctztMWcVzFEY
Message-ID: <CADi0yUM+nC7QDXbAPrxq2RQT2cXPTL18gbeAUXh+=jvio7KEwA@mail.gmail.com>
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary=047d7b472868ccaa6c04e725282b
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug
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: Tue, 24 Sep 2013 18:18:13 -0000

​Uri says:

> Isn't it enough already? Sufficient evidence, including publications by
> respected cryptographers, has been presented to adequately demonstrate
that
> truncating MAC has security advantages over including the entire output
of the
> hash function. That was the primary reason/justification for truncating
MAC in
> IPsec.

​Just to set the historical record straight:

​The motivation for HMAC truncation in IPsec was saving some dummy padding
to obtain 32- and 64-bit alignments (in IPsec headers).​

Once the benefit of such truncation for alignment purposes was identified,
a long debate took place regarding the security risks or benefits of HMAC
truncation. We eventually converged to the consensus that truncation posed
no known risks to HMAC and, moreover, the work of Preneel and van Oorschott
showed that in some cases it may even add to security. This led to IPsec
adopting truncated HMAC and also motivated the paragraph on truncated HMAC
in RFC 2104.

Since then there has been no significant new evidence supporting truncation
or non-truncation. In particular, the prevalent use of HMAC as a PRF (not
just MAC), also in TLS, assumes security for both truncated and
non-truncated HMAC.

One thing is for sure: The decision to truncate a MAC must be done on a
per-algorithm basis. For some MAC algorithms it may be fine to do so, for
others it may not.

Hugo

​PS: Historians may want to consult OLD IPsec archives, for example
www.vpnc.org/ietf-ipsec/96.ipsec/msg00001.html ​

On Tue, Sep 24, 2013 at 8:48 AM, Blumenthal, Uri - 0558 - MITLL <
uri@ll.mit.edu> wrote:

> Guys,
>
> ​​
> ​​
> Isn't it enough already? Sufficient evidence, including publications by
> respected cryptographers, has been presented to adequately demonstrate that
> truncating MAC has security advantages over including the entire output of
> the hash function. That was the primary reason/justification for truncating
> MAC in IPsec.
>



>
> FWIW, the reasoning of that paper applies to SHA3 as well, though arguably
> that extra security measure is unnecessary there.
>
> P.S. Peter, I admire your ability to keep arguing well past the logical
> defeat. <half-smile>
>
> --
> Regards,
> Uri Blumenthal                            Voice: (781) 981-1638
> Cyber Systems and Technology   Fax:   (781) 981-0186
> MIT Lincoln Laboratory                Cell:  (339) 223-5363
> 244 Wood Street                        Email: <uri@ll.mit.edu>
> Lexington, MA  02420-9185
>
> Web:  http://www.ll.mit.edu/CST/
>
>
>
> MIT LL Root CA:
>
>  <https://www.ll.mit.edu/labcertificateauthority.html>
>
>
> DSN:   478-5980 ask Lincoln ext.1638
>
> ----- Original Message -----
> From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
> Sent: Tuesday, September 24, 2013 08:31 AM
> To: <tls@ietf.org> <tls@ietf.org>
> Subject: Re: [TLS] padding bug
>
> Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:
>
> >Since you are the one claiming that MAC truncation isn't necessary when
> all
> >existing protocols do it (even TLS does it on the Finished message MAC),
> it
> >may be better for you to present evidence that this isn't necessary.
>
> Before that, you'd have to present evidence that "all existing protocols do
> it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS
> doesn't,
> SSH doesn't, ... .  In fact of the major IETF application-level security
> protocols that I can think of, only IPsec does, and AFAIK (meaning based on
> long-ago discussions with one of the IPsec folks) that was done in order to
> fit the MAC into the fixed-size AH header (although there seems to be some
> disagreement on the details).
>
> As I've also already pointed out, TLS has for some years now provided for
> MAC
> truncation to a range of sizes.  If anyone's really worried about this,
> they
> can request truncation to whatever size they prefer.
>
> Peter.
> _______________________________________________
> 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
>