[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
- [TLS] Heartbleed / protocol complexity Hanno Böck
- Re: [TLS] Heartbleed / protocol complexity Martin Thomson
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Salz, Rich
- Re: [TLS] Heartbleed / protocol complexity Geoffrey Keating
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Salz, Rich
- Re: [TLS] Heartbleed / protocol complexity Watson Ladd
- Re: [TLS] Heartbleed / protocol complexity Manger, James
- Re: [TLS] Heartbleed / protocol complexity Nikos Mavrogiannopoulos
- Re: [TLS] Heartbleed / protocol complexity Hannes Tschofenig
- Re: [TLS] Heartbleed / protocol complexity Dan Brown
- Re: [TLS] Heartbleed / protocol complexity Watson Ladd
- Re: [TLS] Heartbleed / protocol complexity Hanno Böck
- Re: [TLS] Heartbleed / protocol complexity Martin Rex
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Patrick Pelletier
- Re: [TLS] Heartbleed / protocol complexity Bill Frantz