[TLS] Heartbleed / protocol complexity

Hanno Böck <hanno@hboeck.de> Wed, 09 April 2014 21:25 UTC

Return-Path: <hanno@hboeck.de>
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 E60741A025E for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 14:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.699
X-Spam-Level: **
X-Spam-Status: No, score=2.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 XjpMOwJv62Sf for <tls@ietfa.amsl.com>; Wed, 9 Apr 2014 14:25:12 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1406E1A0234 for <tls@ietf.org>; Wed, 9 Apr 2014 14:25:11 -0700 (PDT)
Received: from localhost (91-64-37-173-dynip.superkabel.de [::ffff:91.64.37.173]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 09 Apr 2014 23:25:10 +0200 id 0000000000020015.000000005345BAB6.000066F6
Date: Wed, 09 Apr 2014 23:25:05 +0200
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20140409232505.0d6e02b8@hboeck.de>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26358-1397078710-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ld01efp2HiRvimdYzaiLS-O9S0w
Subject: [TLS] Heartbleed / protocol complexity
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: Wed, 09 Apr 2014 21:25:16 -0000

Hi,

It's kinda surprising that nobody yet started a thread on the biggest
issue in TLS these days on the TLS WG list. So I make a start.

First thought might be "no protocol issue, software bug, not an issue
for the TLS standardization process". But I think there is an issue at
hand here: We have a severe bug in a rarely used TLS extension.

And: This is the second time in just a few days a TLS extension gives
headache. We just had the Dual EC paper exposing possible security
issues with the Extended Random extension (which luckily never came to
life).

I see a number of issues here:
* Heartbeat extension is enabled in cases where it most likely will
  never be needed or used (HTTPS), but it still causes problems. That
  shouldn't be.
* Extensions make the protocol more complex. Complexity adds attack
  surface. Someone recently said "TLS 1.3 sounds like TLS 1.2 minus
  some features". Probably that's a good way to go forward. IMHO the
  lesson learned should be: TLS extensions shouldn't be added
  carelessly, need good justification and shouldn't be overly complex.
  Same goes for extra ciphers and other things that blow up the
  protocol variations.
* Heartbeat adds some completely unneccessary complexity by having a
  payload with an arbitrary length. There's no point in that. Fefe
  wrote something about it (german only):
  http://blog.fefe.de/?ts=adba343f
  (I don't like his name blaming but he has a point on heartbeat and
  payload)
  Lesson to learn: If it is decided that a new extension is needed it
  should be as simple as possible.

Thoughts?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42