Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Thu, 14 November 2013 23:18 UTC

Return-Path: <prvs=40306ac450=uri@ll.mit.edu>
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 D1C9B11E8123 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:18:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.773
X-Spam-Level:
X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
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 EYEG0UcQ1sCw for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:18:26 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91511E8112 for <tls@ietf.org>; Thu, 14 Nov 2013 15:18:25 -0800 (PST)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id rAENIOJv018235 for <tls@ietf.org>; Thu, 14 Nov 2013 18:18:24 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'tls@ietf.org'" <tls@ietf.org>
Date: Thu, 14 Nov 2013 18:18:23 -0500
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAEmDYAAABmbic=
In-Reply-To: <CEAB0756.EFCA%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_07:2013-11-13, 2013-11-14, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311140176
Message-Id: <20131114231826.0E91511E8112@ietfa.amsl.com>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Thu, 14 Nov 2013 23:18:31 -0000

+1

--
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: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk]
Sent: Thursday, November 14, 2013 06:07 PM
To: Marsh Ray <maray@microsoft.com>om>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:

+1 to almost everything in this post.

Let's now move on to discussing the substantive issues, keeping in the
forefront of our minds Marsh's wonderful phrasing:

"We should always be vigilant and paranoid. But the key to being
*constructively paranoid* is to worry about the *right* thing."

Kenny



On 14/11/2013 21:00, "Marsh Ray" <maray@microsoft.com> wrote:

> 
>Our knowledge of generic hashing constructions has evolved:
>A.     
>Standard constructions
>B.     
>Length extension attacks
>C.     
>Joux multicollisions/²2nd preimages for less work²
>D.     
>Chosen-Target Forced-Prefix (Nostradamus, RapidSSL, Flame)
>E.      
>Sponge constructions
> 
>Attacks against specific hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to
>unfold in sequence:
>1.      
>Reduced round collisions demonstrated (depends on reduction)
>2.      
>Absurdly impractical multicollision and/or collision weakness theorized
>3.      
>Plausible multicollision and/or collision weakness theorized
>4.      
>Full collision demonstrated
>5.      
>CTFP demonstrated
>6.      
>2nd preimage theorized
>7.      
>2nd preimage attack demonstrated
>8.      
>Primary preimage attacks demonstrated
> 
>The last I heard:
>MD4 is at stage 6
>MD5 is at stage 5
>SHA-0 was withdrawn at stage 3 or 4
>SHA-1 is at stage 3
>SHA-2 is at stage 2
> 
>Now let¹s talk about HMAC.
> 
>HMAC uses a double invocation of the full hash function each of which is
>initialized with a secret key. There¹s some pretty well respected proven
>properties
> on the security of HMAC. For example, assuming the key is actually
>secret from the attacker, you generally don¹t need to worry about
>collision attacks. The resulting MAC value or tag can be truncated and
>yet it still retains min(secret key bits, tag bits)
> security.
> 
>In TLS, the secret key is generated by the TLS PRF. The TLS PRF is one of
>the most conservative parts of the design of TLS. It itself uses HMAC
>recursively.
> IIRC, to produce one block of PRF output takes something like 4
>invocations of the underlying hash¹s block function. It functions much
>like a slow, conservative block cipher with 512+160 bits of key and
>secret plaintext input (512+1024 for SHA-2-384 and -512).
> 
>So the concern (C) has been raised that an attacker who may know some
>plaintext, and sees one or more samples of ciphertext, and the
>non-truncated MAC tag around
> this ciphertext, may then be able to ³reach back through² the HMAC to
>obtain the MAC key. This would enable him to forge ciphertext, which
>would enable him to and flip various bits decrypted plaintext bits. (Of
>course the current design allows anyone to do
> this today it¹s just that the later MAC will detect it so it becomes a
>game of oracle testing).
> 
>Additionally, the concern (D) is raised that an attacker who completely
>succeeds with (C) may then be able to ³reach back through² several
>additional layers
> of HMAC in the TLS PRF in order to derive one or both of the cipher keys
>allowing full decryption of the protocol stream.
> 
>To be clear, I say ³reach back through² because I don¹t think there is
>actually a name for this attack model. Even if we were just talking about
>a hash function
> instead of HMAC, this is an attack capability *beyond* primary preimage.
>Primary preimage is ³given h(M), find M¹ such that h(M¹) = h(M)², whereas
>this attack is: ³given h(M), find M²!
> 
>In other words, the attacker doesn¹t get to control the message input.
>Such a feat has never been openly proposed in the literature (that I¹ve
>seen on hash
> functions), not even theorized, not even for MD4.
> 
>But again, our scenario (C) is not the use of plain hash functions. We¹re
>talking about attacking the use of HMAC<Hfn>(k, msg) to recover the
>secret key bits
> of input. This is yet another step removed from ³unthinkable².
> 
>In the case where that the secret key length is the same as the MAC
>length, there¹s even about a coin toss chance there will be two or more
>keys that yield
> the target hash MAC. When the MAC is truncated, there are exponentially
>more.
> 
>But again, for the concern (D), we¹re talking about accomplishing (C) and
>then continuing on to attack the TLS PRF through several cascaded
>HMAC<Hfn>(k, msg)
> to recover the secret key bits of input. This is yet another step
>removed from ³unthinkable².
> 
>My conclusion is that for any reasonable choice of hash function, the TLS
>PRF is noninvertible. To put this another way, if this feat were
>demonstrated even
> using the horribly broken MD5 it would be earth-shattering in its crypto
>impact. It is secure forever, unless there are seriously fundamental
>advances in complexity-theoretic cryptanalysis. And if that day comes,
>*it will be your fast ciphers that you¹ll
> worry about*. The TLS PRF is by far the slowest, most conservatively
>designed stream cipher in common use.
>
> 
>I would never say something is ³impossible² in cryptanalysis. We should
>always be vigilant and paranoid. But the key to being *constructively
>paranoid*
> is to worry about the *right* thing. The security of HMAC<modern
>hash>(secret k, message) is *not* the right to worry about.
> 
>The thing to worry about is block cipher modes¹ propensity to turn into
>plaintext oracles. This has been demonstrated as a practical attack on
>over and over
> again.
> 
>***
>RECOMMENDATIONS ***
> 
>* Put TLS PRF and HMAC security way, way down if not last on the list of
>things likely to negatively affect security.
> 
>For all future TLS cipher suites and TLS 1.3 in general is:
> 
>* Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
>defensible in this age. If you think ³oh but GCM² look more closely into
>its design.
> 
>* Use the NIST-specified truncation SHA-2-512/256 for the HMAC hash
>function.
>
>* Don¹t truncate the TLS record MAC in an attempt to protect the master
>secret (as in the Finished message). Even if such an attack were
>practical, the attacker
> sees many samples of the MAC any way.
> 
>* Do truncate the TLS record MAC to 128 bits because anything more is an
>indefensible waste of bandwidth.
> 
>* Don¹t panic.
> 
>Thanks for reading this far. I¹m fallible. TIA for details, factual
>corrections, and flames. These are my own personal opinions and not
>necessarily those of
> my employer.
> 
>-         
>Marsh
> 
>


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls